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PRELUDE 


A Year In Development is an anthology of stories about the process of designing and manufacturing 
computer systems, told by some 50 employees at four locations across Data General's R & D 
community. Individually, each story represents a unique point of view about some aspect of 
technology or the development process. Collectively, these stories articulate certain fundamental 
truths about systems development and capture the spirit of an R & D organization that has been 
called the most successful in the computer industry. 








A Year In Development is both less and more than its title implies. Less, because it does not 
presume to be a complete account of a year’s development activity — only some of its most visible 
events. And more, because the projects that came to fruition in the course of this book completed 
a three-year process of replacing Data General's product line. 


The process does not stand still, however. Even as we went to press, new developments were 
already underway to evolve the product line a generation-step further. The book, then, is a snapshot 
of this product line and people, frozen in time as they could never be in reality, somewhere on 
the way from what has been to what will be. 


The idea for the book came from our time spent in Data General's R & D community, talking with 
managers and project leaders about their technologies and development strategies. Our job was 
to flow this information through to other areas of the corporation. Yet the information we received 
was so often compelling and articulate that it seemed worth flowing back into R & D. And so, with 
the help of the people in development, we compiled this book. They provided the stories; we simply 
added the narrative glue to tie it together. 


We are grateful to David, who supported this idea from start to finish; to the rest of our colleagues 
for their help along the way; and to Kathleen and Jonathan in Customer Documentation for “The 
Beauty is in the Simplicity” and "The New Executive". 


But most of all we thank those managers, project leaders and developers who contributed their 
insights and experiences to A Year In Development. Data General's most valuable resource is its 
people — particularly these people, who are responsible for substantial pieces of the company's 
product line. This fact led us to adopt an editorial policy of identifying our contributors by position 
or first name only. However, we hope that through the many pictures and stories, each of them 
will know that their contribution is recognized and appreciated. After all, this is really their book. 


P.L.B. 
C.A.C. 


Westboro, Mass. 
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ON OUR TERMS 








Wherever individuals have come together for a common purpose, they have created languages 
that bind them as a community and distinguish them from the rest of the world. The high-tech 
community is no exception, and some readers will find its vocabulary — dense in the acronyms 
and buzzwords of many technical dialects — hard to understand. Knowing this, we wanted 
nevertheless to let people speak in their own terms, and have tried to intrude only occasionally 
with a parenthetical explanation or remark. Our editorial policy, if we had one at all, was to let 
the community write its own book, so that the final picture might bear some resemblance to the 
subject. 


The nomenclature of Data General's product line is another matter. Like the cast of characters in 
a Russian novel, it is idiosyncratic and recurrent, and should be explained here: 


MV/ refers generically to Data General's 32-bit line of computers. AOS/VS, or /VS, refers to its 
bread-and-butter operating system. CEO is an integrated package of business automation software 
that runs on all the MVs. And TEO combines this business software with technical tools for 
applications like electrical engineering or Al development. A native Unix product, DG/UX, is often 
simply ‘Unix’ to developers. And the company’s automated manufacturing facilities are ‘Cornfields.’ 


You will often hear developers use different names for the same product, alternating between its 
codename, its trademarked name, and an abbreviated version. Thus a floating-point enhancement 
to the MV/10000 was codenamed Hawk, trademarked MV/10000SX, and nicknamed MV/10SX. 
Viking, a high-end superminicomputer, was trademarked the MV/20000 and nicknamed the 
MV/20. A distributed operating system called Devios became AOS/DVS, or /DVS. And a single- 
board system called Opus evolved into two workstations — Bulldog, or the MV/2000DC, for offices; 
and Guss, or the DS/7500, for technical environments. Data General's custom MV/ chip set was 
engineered under the name Shrike, with names like Kestrel, Harrier and Coyote for the individual 
chips. In a parallel development there was Kite, or the MV/7800 — the first computer to integrate 
the chip set. Finally, a project named Scorpio became the MV/15000 — a series of mid-range 
superminis based on the single-board Viking CPU. 
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First quarter 
revenues up 
nearly 40%. 


PELL ULL 
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Jim returns from Middle East 
to snow and Opus problems. 
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PCB for Viking control panel 
released to Engineering Services. 


EMC develops spec for evaluating 
high-density connectors. 
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AN ENDING 
AND A BEGINNING 


On Halloween eve, at least one person in Massachusetts and a dozen 
others in North Carolina looked ahead to the new year and saw an 
ending, not a beginning. The next day DEC would announce the VAX 
8600. Tom West watched the parking lot emptying of cars from a window 
in his office and mused to no one in particular, “Just think: our last day 
as the supermini performance leader." 


At that hour, in a lab at Research Triangle Park, a few logic designers, 
a couple of microprogrammers, and one software guru were running 
benchmarks on an MV/10000 with a new floating-point board in its chassis. 
In January their board would be announced as the MV/10000SX. Soon 
after, their project of two years would come to a close. 


The new floating-point unit looked unlike any printed circuit board Data 
General had produced. Instead of row upon row of small, miscellaneous 
logic chips, 17 large gate arrays contained the major logic functions. 
While the competition had struggled for six years to build a machine 
with 1200-gate ECL arrays, these were 2800-gate ECL/TTL hybrids — 
the first commercial application of new semiconductor thinking. 


“Hawk was a power implementation, one of the kinds of things this 
company does best. That board is just a whole lot more valuable than 
merely existing as an enhancement to the MV/10. It let us pioneer our 
technology without having to bet the company on it." 


“What we did was to take an emerging technology and build an en- 
hancement instead of a whole system, a big gamble with a small payback 
that allowed us to take some risks. The first time the Hawk team did a 
design spin with a different gate array, the project went down in flames. 
The gate array vendor couldn't deliver. It's very useful to have only a 
small set of pioneers to take that arrow." 


Hawk — the MV/10000SX — was postulated on a crawl-walk-run theory, 
a phased approach to building new technology into the product line. 
Even before it was completed, attention had shifted to the 15 or so Westboro 
engineers working on phase two ... the MV/20000. 
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A BRIEF HISTORY 


When Hawk was announced in January, the Viking team was going on 
its third and final year in development. Having submitted all the gate 
array designs to Motorola, the engineers busied themselves with testing 
and clean-up and a thousand-and-one small details — which is to say 
that they were really waiting to get their silicon back and start building. 
Most of them had been prepared for “post-partum depression" — the 
sense of loss that follows after a project is through — but gate arrays 
introduced a new element in the development cycle. They called it the 
"mid-life crisis," a crossroad that prompted them to revisit and reflect on 
their past. The following history was compiled by the Viking team during 
this time and added to later as their last year together unfolded. 





1979 Jeff, Pete, Jim, Biagio and Dan enter college. 
1980 Deo enters college. 


1982 
Jan. VANGUARD project started at RTP. 
Jul. FALCON project canned. 


Nov. VANGUARD project moves to Westboro, renamed VIKING. Jim 
marries, goes on honeymoon, considers TAT20 as technology. 


Dec. Kevin's car breaks down. 

1983 

Jan. TAT020 selected as gate array technology for Viking. 

Feb. TAT020 canned. MCA2800ALS chosen as new gate array 
technology. 

Mar. Picasso-2-0-63 released. 

May MCA2800ALS design manual released by Motorola. 

Aug. Tom's barbecue. 


Sep. Picasso-2-0-64 released. CPD moves from Building 14A to 14B. 


Nov. Picasso-2-0-65 released. New MCA2800ALS design manual and 
prop delays released by Motorola. 


Dec. CPD annual conference at Woodstock. First design review. 
Proposed first simulation of a gate array on Zycad. 

1984 

Jan. Dan's Fiero arrives. Gollum sick as a pig. Lynn moves into an 


office. 


Feb. New MCA2800ALS design manual and prop delays released by 
Motorola. Pachyderm MV/10 installed and renamed Paclntosh by 
popular vote. 


Mar. Tony leaves. 3-bit counter simulated on Zycad. 
Apr. Preliminary memory module pc layout completed. 
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OF VIKING 


June Bob moves furniture to Paul's, cats to Myer’s, stays at Pete's. 
Antenna erected at Tom's house. Hole dug for Pete's pool. 

July Jim moves. Schedules shoved two weeks. Jim shoved into pool. First 
array — Kevin's shifter — released to Motorola. ATU array 
released to Motorola by Paul. 


Aug. Bob continues to install shower. Tegas simulation starts on subset of 
gate arrays. Pete opens pool. SPI formed by Bruce, Jeff, Pete and 
Ken. 

Sep. DRP started. Z-80 selected as microprocessor. M33] macrocell mask 


problem forces restart of most arrays and ATU. Tom's house gets 
painted. Tooling hole change puts memory module pc back into 





layout. 

Oct. Placement begins on Will's CPU pc board. CPD annual conference 
at Woodstock. 

Nov. Tooling hole change puts memory module pc back into layout. 


Alpha replaces Z-80 as microprocessor for DRP. Bob's lake is 
drained. M331 macrocell mask problem forces restart of most arrays 
and ATU. 

Dec. Last leech leaves Bob's lake. Viking CPU gate arrays simulated on 
Zycad. Ruth's Christmas party. Routing begins on CPU board. 
Dan's International Harvester truck arrives. Jay goes to East 





Germany. 

1985 

Jan. DRP prototype in lab. Last guest at Ruth’s Christmas party finds his 
way out of Upton. Last design review. 

Feb. Dual FPUs in place at SPI (one active, one hot backup). Vendor 
pack made for memory module pc. System simulation incorporates 
all gate arrays. Alex leaves. ATU has zero yield at Motorola. 

Mar. Bob continues to install shower. One prototype memory module 
assembled and tested at Westboro. Tom QSL’s Bujumbura, Burundi. 

Apr. Vendor pack made for CPU pc board. Additional memory modules 





scrapped in Clayton (bad solder mask). Kevin gets new car. Jim: 
"It's not over until AFTER it's over." 

May Second debug chassis built. Rev 1 CPU in layout. 

Jun. Debug starts on MCU/IOC/DRP. 10 arrays installed on CPU with 
good results. ALU problem investigated at Motorola — schedules 
slip. Marathon engineering seminar held in TV studio. 


Jul. Good news: solution to ALU problem found. All CPU arrays 
installed. 

Aug. All CPU verifiers working with cache enabled. 

Oct. AOS/VS runs on Viking. Jim's wife delivers before he does. 
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HE STIRRUP 





AND THE 
GATE ARRAY 








For many people, technological advances bring to mind the mythical 


"crazy scientist" waiting for an apple to fall. But 


the reality is that more often the state of an art is advanced by the state of its practice — by applying technology in 
a new way. This was no less true in 1066 AD, when at Hastings the Norman army used its stirrups for leverage to 


wield weapons on horseback, than it was in t 


arrays to build a single-board CPU. 


Neither the stirrup nor the gate array were new inventi 
more conventional ways. Nor was the full impact of these 
line derived from one set of printed circuit boards — known in a 
the design emerged from a small set of key goals: 
announce in two years.” While all the engineers shared a sens 
none of them could have predicted its significance as a finished pro 


machines. 


Can you talk about the background of Viking? 


It started, from my point of view, in November of ‘82 
following the MV/4000 announcement. A small group 
of people had been working on the program both in 
Westboro and in RTP — working on what turned out 
to be background, an investigation of technology 
alternatives for a one- or two-board medium- or high- 
performance system to replace the MV/10000 at the 
high end. But the goals weren't firm at that time. We 
investigated several technology alternatives involv- 
ing high-density CMOS — 6000- or 8000-gate array 
CMOS — along with bipolar arrays like the Texas 
Instruments [TI] TATO20 which disappeared shortly 
thereafter, as the Hawk project discovered. And in 
January of 1983 we found out about the Motorola 
2800 ALS — a second-generation bipolar technology. 


We proposed a couple alternatives and several dif- 
ferent system sizes; then the word came down from 
on high that we wanted higher performance. So we 
said OK, what do we need to exceed 5M Whetstones 
given a general processor organization similar to the 
MV/10000, which was pretty effective. We weren't 
going to be doing a board per unit like the MV/10 
was, but we'd be dividing up gate arrays along 
similar boundaries. In choosing a component tech- 
nology we asked, Well, for 5M Whetstones, what kind 
of processor cycle time do we need? We came up 
with a number and determined that the technology 
was available to make it with 2800 ALS. We pursued 
it, along with appropriate RAMs that would fit into 
that cycle time as well. And we managed to keep 
our cycle time constant through the remainder of the 
development. It turned out that we were more effec- 
tive in our microcoding and architecture than origi- 
nally estimated — we ended up with over 6M 
Whetstones in the Viking uniprocessor. 


You seem to specialize in working with very heavy 
design constraints, in that this is a high-powered 
CPU on a single board, and your previous machine 
was the MV/4000 which was a two-board CPU. How 
different is that from an MV/10000? 


The MV/10000 was defined as roughly two times the 
MV/8000 in performance with no real constraints per 
se on form factor. However, conveniences of design 
and functional unit partitioning do impose form factor 
limitations on you when you're in the middle of de- 
sign. A functional unit really wants to be as self- 
contained as possible. For example, the address gen- 
erator on the MV/10000 conveniently wants to be 
one board. Most of the components talk among them- 
selves with a few well-defined interfaces to the rest 
of the system. The same with the ALU board or the 
floating-point unit. 


The MV/4000 was actually a two-board CPU system; 
Viking is a one-board CPU. The constraints on Viking 
didn't really say it had to be one board, it had to 
be two. The single-board design really came about 
by asking whether a two-board CPU made sense for 
the performance we wanted. And it really didn't, 
because of the extra time delay you have in talking 
between boards. 


I believe that working under heavy constraints with 
few degrees of freedom can be much more chal- 
lenging because it requires more innovation. As long 
as the goals are challenging, the constraints are 
challenging. If it's easy to fit into those constraints 
then it's not quite so interesting to do it. The MV/4 
was not a piece of cake, nor was the MV/20. 
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he mid 1980's when the Viking engineers used the higher density of gate 


ons: the competition knew of and even used them, although in 
devices — a new era of military practice, or a new product 
dvance. As the Viking program manager relates here, 
"Let's build a 5- or 6-MIPS processor on one or two boards to 
e that what they were building was state-of-the-art, 
duct or the influence it would have on future 


How did you find something that was going to be 
state-of-the-art from a couple years out — say start- 
ing in 1983 and it hits the market in 1986? 


Basically you choose a technology that's immature. 
It sounds a little crazy and a little risky but the 
Motorola 2800 ALS was not mature — it hadn't been 
out in the market and proven for two years. It was 
in the definition and testing stages when we started 
discussions with Motorola, and it was about two years 
after that before it really matured. We became the 
industry's first user of this technology. To be state- 
of-the-art you need to pick that leading edge tech- 
nology and go with the vendor while he's finishing 
up and developing his process. 


How risky is that while you're designing the ma- 
chine? 


It's pretty risky, but if you have a reputable vendor 
who's not doing something really unusual, it's not 
too bad. They weren't doing an extremely obscure 
process — they were tightening up geometries and 
using other pieces of process for bipolar, restricting 
sizes of the transistors in ways that other vendors 
were doing too. 


In a sense the Hawk project [later the 
MV/10000SX] minimized the risk for the rest of us; 
they had to respin all their arrays in another tech- 
nology when the TATO20 was put aside. 





Other aspects of being state-of-the-art one or two 
years out: you've got to pick a target that goes beyond 
what you think your competitors are going to do. 
There's a lot of guess work involved there. The 5- to 
6-MIP target was, | think, correctly chosen by man- 
agement as what we had to do to exceed the com- 
petition — and clearly they were right. And where 
we ended up with form factor makes us clearly su- 
perior to anything else that's available in that per- 
formance range. 


State of the art means not only pushing semicon- 
ductor technology, it also means pushing connector 
and pe board technology. On Viking and on other 
programs too, we went to a finer line width so we 
could get greater density on the boards — another 
increment above what the previous high-density board 
had been. 





Could you elaborate on some of the technologies 
used on Viking? 


In order to get all the functionality on a one-board 
CPU we needed a very dense silicon technology, 
and that's what Motorola's 2800 ALS gave us. The 
complexity of each array is equivalent to that of the 
original NOVA 1200. People have mistakenly called 
Viking an ECL machine, maybe because Motorola 
also makes a 1200-gate ECL array that other com- 
panies have used in their machines. But this is a 
newer hybrid technology. It allowed us to use ECL 
for the main data paths where speed is important, 
and TTL for the less critical I/O and memory circuitry, 
where we wanted higher density and low cost. So 
we had the best of both worlds. 


Before we could even think about designing the ma- 
chine, we had to invest in a set of CAD tools that 
would run on our MV/10000s. We have a bunch of 
MV/10s that allow us not only to design but to sim- 
ulate each of the gate arrays independently to make 
sure they function properly, and then to simulate the 
entire Viking system. That's a monumental under- 
taking: it took six months of MV/10 simulation time 
to simulate a second of Viking execution. 





The CPU board has eight layers and the minimum 
line width and spacing on it is six mils, or about 
three human hairs wide for each of the conductors. 
With that kind of density, we needed a very high 
degree of signal communication between pc boards 
and the backpanel. Historically, DG's 15-inch boards 
had two edge-connector paddles each with 100 pins, 
and those pins brought all the power, signals, and 
grounds onto the board. In a machine of Viking’s 
complexity, that number of pins represented a severe 
design constraint — to get our required bandwidths 
we had to invent a higher-density connector. The 
new connectors have 240 single pins each, giving 
us 480 pins on a board. We can now use all the 
signal pins to carry signals. 


I understand that a part of Viking was developed 
in RTP — how did that work from a distance? 


The people who did the floating-point unit for Hawk 
were by and large the same people who did the 
Viking floating-point board. Hawk was the first project 
to use 2800 ALS, so the RTP group was already 
experienced with the technology. But there were a 
number of differences in the interface between the 
CPU and FPU, so we did have to work closely to- 
gether. And that integrated into the Viking project 
very smoothly. It was a well-defined and effective 
interface between the two pieces of hardware and 
it clicked extremely well. I believe that's worth men- 
tioning — that it's possible to have groups working 
in widely separated areas and get well-defined in- 
terfaces. I think it's an excellent example of how that 
can work. 





You also defined a multiprocessor aspect to the 
system early on. I understand that there was some 
degree of resistance to the concept. How did you 
push that toward reality? 


The reason for the resistance was because everyone 
thought, ‘Oh God, multiprocessor — all the hardware 
that's got to be devoted to the multiprocessor.’ Well 
it turns out that the way we defined our system bus 
and our caches — 99.9 percent of the hardware you 
would need to run two CPUs in parallel was already 
built in to support a uniprocessor with an I/O chan- 
nel. For instance, when an I/O device writes into 
memory the data integrity in the caches has to be 
maintained. So whether you've got two processors 
or one processor and I/O, you have to maintain data 
integrity in your cache. We implemented a write- 
through cache as opposed to a write-back cache, 
which means every write to memory from the CPU 
goes directly to memory. And I/O of course is not 
encached anywhere. So the CPU and I/O systems 
are really like separate processors running in par- 
allel. Therefore if you solve the problem for I/O, it's 
automatically solved the problem for another CPU. 
That's generally considered one of the big problems 
that requires additional hardware. 


The only extra hardware we added to support mul- 
tiple processors was some specific and very limited 
interCPU communication hardware that we put on 
the memory and I/O controller board. So that part 
of the argument against multiprocessors was pretty 
much cancelled. 
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The other argument was how much it would take to 
make a multiprocessor operating system. Well, that's 
harder, because that involved real work (laughs). It 
wasn't already defined in the uniprocessor /VS, but 
John [the principal software designer] presented it 
as a relatively straightforward job that could be han- 
dled in the software. And we said, ‘Look, we'll put 
two processor slots in the backpanel so the hard- 
ware’s all set. All you need is the software.’ The joke 
is that now the /VS group really had it's work cut 
out for it — they did the lion's share of the imple- 
mentation, although we were at least able to limit 
the size of the job. We all wanted to do it and make 
it work, and we did. By adapting the hardware for 
a perfectly coequal multiprocessor, it was easier for 
software to get close to full utilization out of both 
processors all the time. 


It's common knowledge that there was a lot of 
pressure on this program. How do you deal with 
that? 


Not easily. I think we learned some lessons from that 
experience. A few things that you can do: first of all 
you try to avoid that pressure to begin with — it's 
all right to work under pressure, but when it gets too 
intense, things start to get very tiring. And too much 
pressure actually slows things down. There's only so 
much — you've gotta work this weekend, you've gotta 
work that weekend with no end in sight — that a 
person can stand. The joys of making your project 
work — and there are a lot of those — do end up 
paling when you've been working at it too long. 


One of the other things is to have sufficient resources 
or more realistic schedules, one or the other. The 
announcement was probably scheduled too soon from 
the point of view of product development, although 
not from the marketplace point of view. From a per- 
sonnel standpoint, either more resources to get the 
job done faster or more flexibility in the schedule 
would help. 


Is there one part of the project or the design you're 
most proud of? 


That's a very difficult question to answer because 
on the whole, there are so many different things in 
the machine that are done well by so many different 
people. It's tough to pick one aspect and say I feel 
best about that. I don't see one thing that stands out 
as being superior above all the others, so much as 
lots of interesting pieces and clever things done that 
make the whole machine superior. There was really 
good optimization made in the caches and address 
translation, and the ALU, the memory system, and 
the system bus ... I could make a long list of things 
that I think are really neat. 
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It seems that North and South have always presented us with studies in contrast. If the pressure was inexorably rising in Westboro, 
which had yet to deliver product, it was just as surely falling in Research Triangle Park, which had already come through. By 
January's end designers in RTP had pioneered the first commercial use of MCA2800 gate arrays in the MV/10000SX; integrated 
Unix into the company's product line; and delivered the software and documentation for the DATA GENERAL/One, industry's 
first full-function, portable PC. The celebration was staged on a winter night in Chapel Hill, where the crowd joined hands in a 
circle dance around the ballroom, the hotel staff looked on in terror, and singer Eve Cornelious exclaimed in wonder and triumph, 
"You're beautiful people — I'll play for General Data every time!” 
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THE LITTLE ENGINES 
THAT COULD 


A designer here once defined technology as an answer in search of a question. This was his way of describing the 
relationship between marketing and development, or the product and the design — a process of taking emerging 


technologies, mapping them onto emerging markets, and delivering the appropriate solution within a two- or three- 
year horizon. 








So it happened that the Opus project had pioneered an impressive body of workstation technologies by its second 
year in development; technologies that were now ready to be focused on specific market needs. First there was the 
silicon choice: 8K CMOS gate arrays from Fujitsu for high density and low cooling requirements. Then, a four-chip 
CPU and FPU that could be embedded with other functions on the same board. A fast local bus for direct connection 
between memory and peripheral devices. And a solution for high-speed graphics processing at a minimal cost to build. 


A product of these technologies would be something like a Shelby Cobra among workstations, which most other 
companies assembled like pine-box derbies from off-the-shelf parts. As it turned out, Opus became two products: 
Bulldog, or the MV/2000DC, a low-cost office system; and Guss, or the DS/7500, an entry-level technical workstation. 
These were the industry's first demonstration of a "no-bus” architecture, integrating all 32-bit system functions on a 
single pc board. 


In February, as gate arrays arrived from Fujitsu, the Bulldog and Guss projects began optimizing the Opus technologies 





for their markets. To get a view across all three development efforts, we talked with key players from each. 


Breaking the Barriers 


[To Dave, project leader of Opus] What was the 
fundamental goal of Opus? 


Our basic goals were to build a complete MV/system 
on a single 15-inch printed circuit board, and to get 
the best possible CPU performance out of the least 
number of chips. 


Why a single-board system; why not multiple boards? 


One place where you really lose things in computing 
is in partitioning. Each time you add a board you 
need a connector and some interface logic to another 
board. A lot of performance is wasted in making 
those boards talk to each other, and they don't quite 
share the logic on the system as efficiently. A single- 
board system optimizes performance because you've 
eliminated propagation delays between boards. 


Another real benefit comes in the integration of all 
the common functions: for example, having one bank 
of chips that handles all the I/O, instead of dupli- 
cating functions on different boards. That means your 
reliability goes up and the cost goes down, because 
you've minimized the amount of circuitry needed and 
reduced the number of interconnects. 





What were the goals of the CPU implementation? 


We wanted to implement the CPU using components 
with the highest density and the lowest power con- 
sumption. We decided on 8000-gate CMOS, the lead- 
ing edge of this technology, and we aimed for a fast 
development cycle so the technology would still be 
new when the product became available. 


When a new semiconductor technology emerges there 
are two things you can do. You can take an existing 
design and retrofit the new technology to the design. 
But if you want to derive the most benefit from an 
emerging technology, you should redesign the target 
machine to complement the parameters of the tech- 
nology. 
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We designed an MV/ specifically for these gate 
arrays. The CPU was implemented on three ar- 
rays — one each for the arithmetic and logic unit, 
the address translation unit, and the microsequencer 
and instruction processor. A fourth array implements 
the floating-point unit. 


What are the difficulties involved? 


Probably the most important factor in designing for 
this type of implementation is the ability to manage 
within a limited budget of gates, microcode lines and 
pe board real estate. Every function that's owned by 
every design group has to conform. We don't have 
the freedom to use a couple of extra chips. 
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How did the choice of technology change the way 
you had to design the CPU? 


It's been a different experience, working with gate 
arrays. In past projects we would design the board, 
build it, and debug it in the lab; it was easy to 
change a wire or a chip if you made a mistake in 
your design. 


With gate arrays, it's very expensive in both time 
and dollars to build the part, and typically the ven- 
dor's only guarantee is that the gate array you get 
corresponds to the test patterns you submit to him. 
So it's critically important to debug the design before 
the vendor makes any parts. That's why there’s so 
much emphasis on front-end testing. 


With Opus we invested in a whole new set of tools 
so we could test our designs by simulation. In typical 
simulations you enter a model, a software description 
of what your circuit looks like, and then you write 
test patterns for it — a series of inputs — and simulate 
how the circuit will behave. Unfortunately, that just 
isn't good enough if there are big areas of hardware 
that your tests have missed. So we also do fault 
simulation — a way of inserting faults in the array 
and then checking to see if our test patterns catch 
them. If they don't, we have to go back and improve 
the test. 


All this is analogous to taking a prototype board in 
the lab and debugging it ... only we had to get the 
bugs out before we saw our first array! 


Of course, if we could model perfectly we could 
design perfectly and just plug everything in, but the 
tools to allow us to do that aren't there yet. We were 
really pushing the limits of what today's best tools 
could do — and that’s an investment in supporting 
hardware and software that runs in the millions — 
just to simulate the whole gate array set. That's a 
far cry from modeling the system perfectly. 


But although a simulation may not be the perfect 
representation, if you've done it right it's good enough. 
As it turned out, only one of our gate arrays had to 
be spun to take care of glitches, so we must have 
done something right. The investment in tools really 
paid off. 


What were the simulation tools? 


We used Tegas, a software package we bought out- 
side, and a Zycad system, a million-dollar box that 
enables us to simulate logic. The Zycad system needed 
a bunch of software to allow us to use it, and that 
software was developed internally by the CAD tools 
group. We also benefited from a microcode simulation 
package that was developed here in CPD. 


Beyond simulation, were there other tools that you 
found particularly useful? 


Yes, we also had Instant, a timing analysis tool built 
in RTP for the Hawk program. Instant helped us get 
all the critical circuit timing right by calculating the 
propagation delays of any specified paths in a circuit. 
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[To Mike, graphics project leader] Turning to the 
Opus graphics technologies, what were some of the 
larger design issues there? 


The fundamental problem was a function of the tra- 
ditional von Neumann architecture — a one-dimen- 
sional model of memory where every word or byte 
has its own address, numbered from one to infinity. 
It's sometimes called linear memory, and it's one 
reason why general-purpose computers do poorly at 
graphics — because the preferred mode of address- 
ing for graphics is an x-y mode, not a linear one. 
So ideally you'd like a two-dimensional model of 
memory. 


How did you solve that problem? 


We came up with a new kind of memory controller 
we call the magic gate array. Basically, the magic 
gate array speeds up graphics processing because 
it makes memory look two-dimensional to applica- 
tions that want to plant dots on the screen. 


For example, if you look at the execution of a program 
that wants to draw a line, it’s split into three parts: 
setting up the line, figuring out where the next pixel 
is going to be, and then planting the pixels. Unfor- 
tunately, one of the most popular ways to plant a 
pixel involves 24 separate bits that have to be set, 
and they're scattered in memory all over the place. 
So the average CPU might read 24 words, insert a 
bit in each, and write 24 words back to complete the 
operation — which takes time. 


For the same operation, a magic gate array says, 
‘Set the pixel x address, set the pixel y address, here 
are the 24 bits you're going to merge into all the 
planes, go and do it, bang — you've just boosted 
performance by a potential factor of 10! That's why 
it's a magic gate array. 


You also enhanced the old Graphics Instruction Set 
to produce GIS II ...? 


Yes, the graphics microcode group was responsible 
for that. GIS II is basically an addition to the MV/ 
instruction set to support an operating system inte- 
grated with windows and application-level graphics. 


The original version of GIS allowed you to plant dots 
on a screen directly, with simple instructions. What 
it didn't allow was for classic, dumb programs to 
believe they were talking to an entire terminal while 
in fact each program was running in its own indi- 
vidual window. 


The challenge for GIS II was to do the instructions 
in such a way that a process can be scribbling lines 
in one window, and it won't interfere with another 
process scribbling lines in another window. We solve 
that problem by allowing each program to have both 
a physical bitmap, which defines the content of a 
window as it appears on the screen — and a virtual 
bitmap, which defines the entire content of the pro- 
gram's window even though it may be partially ob- 
scurred under other windows. The GIS instructions 
handle the drawing in both physical and virtual bit- 
maps so that a user’s program doesn't have to know 
the difference, and the operating system doesn't have 
to oversee each drawing operation to prevent one 
program from overwriting another. 
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Could you more or less summarize what Opus ac- 
complished? 


Dave: With Opus we broke the barriers. We built a 
CPU small enough so that a single board could 
accommodate a complete system, including memory 
and I/O, but fast enough to meet the performance 
goals we had to hit. And Mike's group came up with 
a really state-of-the-art implementation of affordable 
high-resolution graphics, again with the right per- 
formance parameters. 


The Bulldog and Guss projects went on to hit the 
principal product goals — designing in the economies 
to produce an office workstation that had to have 
the lowest cost per user in the industry, and a tech- 
nical workstation that required very attractive price/ 
performance and functionality at the entry level. 


1] 
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Excellence by Design 


[To Don, Bulldog program manager] First, I'm cu- 
rious about how these projects get named ... Why 
“Bulldog?” 


We wanted to convey the idea of small and powerful 
— a real fighting machine. “Bulldog” seemed to be 
appropriate. Somehow the dog theme got carried 
through to other parts of the project: we had a "Tic" 
array for the I/O system. 


And Guss stands for Graphics something System? 
No, Guss is the name of Larry's Doberman ... 
Turning to the project, how did Bulldog come about? 


The idea was to develop an entirely self-contained, 
integrated office workstation in the 4 to 24 user range 
for the lowest possible cost. Opus gave us the CPU 
on a single-board system. The Bulldog project went 
on to implement some redesign to meet certain per- 
formance requirements demanded by the OA/com- 
mercial marketplace. We implemented a new high- 
performance I/O design and a new memory control 
unit, and we designed an integrated system using 
this as our basis. For the most part, what we did for 
Bulldog we flowed through to the Guss product as 
well. 


What were the main design goals? 


Several ideas drove the program. First, we wanted 
these systems to be as inexpensive to manufacture 
as possible. Second, they had to be easy to use. 
Third, Bulldog had to integrate the right amount of 
memory, disk, I/O and what-have-you for an entry- 
level office application, yet still be capable of ex- 
panding to support 24 OA users. 


But the key attribute was to have a balanced system; 
a system where every component — CPU, memory, 
I/O, disk, and so forth — has the right performance 
characteristics for the applications being run. And 
balanced in the sense that all the components run 
out of gas at the same time. 
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How did you go about the implementation? 


We'd learned a lot about designing integrated sys- 
tems from the DESKTOP GENERATION program, but 
we still had some things to learn about shaving costs 
to the bare minimum. We were able to take advan- 
tage of our division director's experience in this area. 
He helped us tune the system definition and worked 
with other parts of the corporation to knock cost out 
of the program. He was also very effective as a 
project advocate, getting all the different groups who 
had to be involved signed up and committed to the 


program. 


To keep the project running as smoothly as possible, 
we tried to really get our act together in terms of 
coordination. We'd set our sights for a really excellent 
product, so it had to be an interdisciplinary effort. 
All the groups involved in the project — hardware, 
software, peripherals, documentation, manufacturing, 
field engineering, marketing, the lot — were signed 
up from the beginning to make the program happen. 


Getting back to your goal of a balanced system ... 
how do you design for that target? 


The biggest part of that was the new design work 
we did on the system board, the I/O section in 
particular. For interactive office automation, you need 
to make sure that heavy I/O traffic from a disk, the 
floppy or some other device doesn't have an adverse 
effect on the response of any other device, or on the 
real-time interrupt response with the user terminals. 


So for Bulldog we built a special I/O section where 
the channels supporting the different I/O devices all 
have high-speed independent access to memory, and 
there's a queueing mechanism into the I/O processor. 
We also prevent potential bottlenecks in the I/O 
processor by off-loading real-time interrupts; we de- 
signed a new gate array — the Tic array — to do 
that. 





And the low-cost goals? 


The rule was ‘keep it simple’, and every design group 
— electrical, mechanical, power engineer- 
ing — conspired to strip out the fat. They looked at 
the sheet metal, the backpanel, the connectors ... at 
any costly element that serves no useful function at 
the low end. 


After all, if all I need is a CPU with enough memory 
to run my application, why should I pay for a back- 
panel — this huge pc board with all these connectors 
on it that I'm not going to use? A connector costs 
about $10 and there may be 40 of them: that's $400 
in materials alone! By making the boards stackable, 
each option absorbs the cost of its own connectors. 
That way, customers only pay for what they need. 


A metal chassis is nice if you want to do a Masterlock 
commercial and shoot bullets through it. But we were 
designing a piece of office equipment: people aren't 
going to abuse it too much. The plastic pedestal on 
the MV/2000 is ideal — it's strong enough to sit on, 
it contains all the EMI protection needed, and it's 
got more than enough volume. So the chassis we got 
is not only more appropriate for the office environ- 
ment, but it costs much less to manufacture than the 
traditional mechanics used by our competitors. 


The typical power supply has wads of intermediate 
cabling — that's all hand labor. Our design elimi- 
nates the internal cabling completely. We designed 
the power supply to fit on half a board and put all 
the external components on the other half. Once it's 
built and tested, the board plugs into a sheet-metal 
tray with a cap on it, and the tray goes into the 
plasic pedestal with a few screws to hold it down: 
acompletely self-contained module. Our ac line plugs 
directly into the power supply, and that's it. One 
cable: and a whole lot of saving. 


It's amazing, the little things you can do that have 
a big impact on the final machine. Here it was the 
things we left out of the product that make it so good. 


What about the ease-of-use features? 


Including all of the appropriate groups early on in 
the project was the main thing that helped us there. 
For instance, the engineers who designed the power- 
up diagnostics worked closely with Field Engineering 
in the very early stages, putting in an enormous 
effort to develop the most accurate diagnostics they 
could. The result is diagnostic software which Field 
Engineering rates as excellent. The same kind of 
input helped us design in the features that make the 
system easy to install and repair. 
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That sounds like a departure from projects I've heard 
about in the past, where groups didn't always get 
onto the program early enough. 


It's not only a matter of when they get involved; the 
quality of interaction is also very important. All the 
groups need to become a part of the development 
team for this kind of product. Take the relationship 
between development and Apex manufacturing: we 
had people from both sides working together in Apex 
and in Westboro to get the system as inexpensive 
to manufacture as we could. The result is that 
MV/2000DCs are being assembled and tested on a 
single, continuous-flow production line — state of the 
art manufacturing. 


The same thing happened between software devel- 
opment, software release and software manufactur- 
ing in Southboro, with the result that Bulldog is the 
first DG machine to ship with the system software 
pre-installed on the disk. 


DAE and development also worked very closely to- 
gether. Traditionally, because of the nature of their 
different roles, these two groups often find themselves 
in conflict. But on Bulldog, DAE engineers were in- 
timately involved in the program — in fact they were 
testing and helping us debug the product before it 
went for final DAE qualification. Everyone benefited 
from that. 


We also had the communications hardware and soft- 
ware designers who developed the I/O option boards 
and made sure all of DG's communications software 
would run on the system. They were heavily involved 
in the debug effort as well. 


How did you manage to finish the project in under 
a year? 


Only by having all the design groups work as closely 
and intensely as they did. We had no choice. (laughs) 
Of course, Opus gave us a head start with the CPU 
and system board. But when we decided we needed 
to redesign the I/O system, we were in real trouble. 
There is no way we could do it in time. The designers 
from Chandra's group saved the day. They dropped 
their own project, came in and helped design the 


I/O gate array in about three months, literally work- 


ing around the clock. 


The synergy between all the different groups on this 
project was incredible. I believe we succeeded be- 
cause of that. Almost by definition, an integrated 
product has to be integrated in development; yet in 
practice it takes a lot of discussion and negotiation 
between organizations that are used to doing things 
their own way. What really hit home for me on this 
project is that people will listen to each others’ con- 
cerns and come to the right decisions together when 
they share the same goal. 
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Akihabra, Tokyo: an electronics emporium where vendors hawk their 


products indoors and out 


Near the end of the month a few DG engineers boarded a 
JAL flight to Tokyo with some overheads sketching out new 
development ideas. Two weeks later they returned bearing 
not only pictures, but new agreements with Japan's major 
technology vendors. They had been making these visits for 
several years now on the conviction that the buyer and 
vendor should act as a team, each sharing his knowledge 
with the other so neither is surprised, and building a co- 
operative relationship where everyone wins. It seemed to 
be working — the plan to use 8K CMOS arrays in Opus, 
for instance, had been hammered out on a similar trip two 
years before. 


While most U.S. businesses have been slow to adopt these 
kinds of partnerships, Data General learned their value from 
its experience with Nippon-Data General [NDG], its business 
and development partner in Japan. The influence began in 
1980 with a laser printer program, on which they learned 
to work together. Then came a 1/4-inch streaming cartridge 
tape drive, their first successful joint project. The next pro- 
gram was even more ambitious: the first processor imple- 
mented by NDG. The MV/8000C used state-of-the-art 256K 
DRAMS that were not then available worldwide, and local 
Japanese design tools were used in the development of its 
high-density, Fujitsu CMOS and bipolar gate arrays. In 1982, 
NDG took on not only development but high-volume man- 
ufacture with the DATA GENERAL/One. The result, deliv- 
ered in 1984, was called a "technology tour-de-force" by 
Byte magazine and voted “product of the year” by PC Week 
and Electronic Products. 


Managers and engineers on both sides have acknowledged 
that working together hasn't been easy. But they will also 
tell you that the cooperation between their businesses has 
given them preemptive opportunities in the technology mar- 
ketplace. And so the dialogue between East and West con- 
tinues, and the partnerships expand. 
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he .ol 
' augagaa 
CH \aanaaaay 
a anaes 
4S : 
1190 
2a 





In the Strolling Garden The Happy Bus 
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At a signing ceremony with Hitachi 


Hoshakawa-San, head of gate array engineering at 
Fujitsu, receives a token of appreciation 





The gang at Sorpora Beer Hall What MacDonald's calls Christmas, the Japanese 
call Gift Giving Season 
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SUNDAY MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY SATURDAY 











Mary, Pat and Susan honored at Women 
of Achievement awards ceremony in Durham. 


Sunnyvale open house: 
Easter rabbit lays 1,000 eggs. 


DG/One voted “Most Significant Product of 1984” 
by PC Week, “Product of the Year” by Electronic Products. 


Graphics welcomes 
Michele. 


Birthdays: 
St. Pat's and John 


St. Patrick's 1 7 ' Vernal 
Day a Equinox 


Amazing poster condenses 
DESKTOP installation manuals. 
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A NEW VISION 
FOR SUNNYVALE 


In March the Westboro engineering lab began filling up with debug stations and testbeds for the new hardware. Meanwhile, in 
a small, rather quiet area at the back of the lab, the Kite project dragged on as it had for at least three years. Stacked inside a 
chassis were 10 high-density, wire-wrapped TTL boards emulating five custom-designed chips — the MV/ chip set, or Shrike — 
which still didn't work. 





Three thousand miles away in Sunnyvale, California, where the chips were now, a soft-spoken man stood before an assembly 
of skeptical employees, introduced himself as their new vice president, and told them that together they were going to rebuild 
Data General's semiconductor division. If no one believed him at first, it's not surprising — similar promises had been made in 
the past but had never quite been delivered. 


Eight months later, when a working Shrike chip set was delivered to Westboro, people would be telling quite a different story. In 
the following interview Sunnyvale's new VP describes the conditions that existed upon his arrival, and how the success of the 











Shrike program contributed to the renewed outlook of his organization. 


The Shrike program had been in progress for four 
years upon your arrival in Sunnyvale. What state 
did you find it in? 


Coming into this program | found several things. For 
one, the process technology and wafer fabrication 
operations were incapable of supporting the project. 
There was a prevalent manufacturing mentality in 
the process engineering organization, leadership was 
weak ... Shrike needed a new silicide process and 
the one in use wasn't producing adequate results. 


The program had dragged on for some time and had 
undergone several management changes. The latest 
management team had worked hard to move the 
project forward, but inadequate process technology 
had led them to develop their own set of design 
tules — it was like the fox watching the chicken coop. 
In fact, that was true in a number of areas — design 
discipline was lacking because of the length of the 
project and turnover of people involved. There were 
insufficient ground rules to prevent people from tak- 
ing unnecessary risks, no such thing as doing a 
boundary-condition analysis — a worst-case analysis 
to make sure something is makeable. It seemed that 
many of the chips had their own process rules, with 
no uniformity to the process structure as a whole. 
And the design methodology and CAD tools, although 
improved somewhat, weren't state of the art. 


There was also a lack of teamwork among the various 
engineering disciplines. People were assuming things 
on their own, and on such a complex program you 
need significant lateral cooperation. I suspected that 
because the specification of the product had dragged 
on for four years, there must now be some differ- 
ences between the intent, the emulator, and the actual 
chip — differences that would take several iterations 


to straighten out. Under these circumstances, I cal- 
culated it could take us another three to four years 
to complete the project! 








A representative group of the Sunnyvale process and 
design engineers who built the chip set. 


But it was actually completed over the next eight 
months ... What happened? 


Our first and foremost focus was on the process 
technology and reducing throughput time. We quickly 
began establishing the right ground rules, and brought 
up a new silicon process. We recruited two top-notch 
process engineering managers to cover the fab-ori- 
ented and device-oriented disciplines. And it turned 
out that we had good talent inside the organization. 
We developed an extremely powerful process engi- 
neering organization, properly molded and directed. 
Things started improving almost immediately. 


With more discipline and parameter controls in the 
process area, we were able to reduce throughput 
time significantly ... nowadays we get taken for 
granted for turning things around in two weeks. In 
fact, everyone walks around saying, ‘Oh if we have 
another spin they'll turn it around — no problem. 
That has to be one of the major improvements that 
contributed to the success of the Shrike project. 
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The next step was to review all the chips as to 
commonality of process and discipline. We launched 
the baseline program — a common denominator 
which all the designs had to fit; otherwise we 
would've had a nightmare. We also studied the chips 
to see that there were no design rule violations, no 
tricky circuit techniques, and that the reliability ground 
rules were adhered to. As a result there were some 
significant changes in the designs, probably two years’ 
worth of time had we not reduced our throughput. 
As it was, we were able to turn each iteration around 
in two weeks. When all the problems got resolved 
and we were able to run AOS/VS — that was our 
first taste of success. 





The Westboro core group that designed logic for the 
chips. 
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A Kite testbed in Westboro. 


After we got the process and design programs going, 
the question became, ‘What will we have when we 
get there?’ Being over four years since the project 
began, the original performance target seemed a 
little ho-hum. One answer was to build the slower 
version, produce it, and then speed it up — everybody 
recommended doing it that way, a step at a time. | 
rejected that. I said, ‘We don't want a bronze medal, 
it's already been four years!’ Our position was to ‘go 
for the gold’ — go for the faster version and deliver 
a product that measured up to customers’ expecta- 
tions. I presented this proposal to Tom West and Bob 
Miller — it was what they wanted, they gave us the 
go-ahead. 


Once it was agreed on, we had our campaign — it 
was called "Shrike by Christmas.” We stepped up 
communication between Sunnyvale and Westboro, 
they helped us firm up the specifications and func- 
tional details. One by one the chips started working 
on the Kite system in Westboro. Kestrel, the CPU and 
ATU chip, took six iterations before it ran AOS/VS. 
It was very exciting to see the teamwork and the 
significant cooperation between the two groups. On 
December 2] we had a fully functional system run- 
ning AOS/VS at 320ns — that was the goal and we 
met it. 
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To take a culture in the state it was in when you 
came to Sunnyvale, and to change it to a success- 
oriented culture and then to a future-oriented cul- 
ture, is a very complex set of moves to make, and 
difficult to pull off, particularly in a very short time. 
How did you do that, how is it progressing now? 


You put it very eloquently — | think that's exactly 
the kind of transformation that took place. The first 
priority for Sunnyvale was to establish some lead- 
ership, a vision of long-term success that people could 
rally around. You may have the best strategy in the 
world, but if people aren't behind it you can't do 
anything. 


We also spent a lot of time in Westboro talking to 
the engineers, our customers, learning about their 
problems and criteria for success. It was important 
for us to characterize our customer base — to es- 
tablish who the important people are and what they 
need. But we didn't succumb to pressure and promise 
things we couldn't deliver — I'd say, ‘These schedules 
aren't realistic, they're what you want to hear.’ Com- 
ing clean about what we could or couldn't do helped 
us establish some credibility. Then we accepted the 
challenge to deliver something the company needed. 
And finally, we demonstrated that we could succeed. 


wenn 
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Testing and verifying chips on the Century Test machine. 


There was a general feeling in Sunnyvale around 
that time ... People started becoming more demand- 
ing of themselves, started calling things as they were. 
The attitude became, ‘We're getting so much better 
so fast, maybe we can win here.’ Sunnyvale had 
been in a survival mode, not a win mode, and giving 
people a win opportunity was dramatic. 


Having success as a platform, we could start looking 
towards the future. Part of my function is to broaden 
our technologies, to invest in companies that broaden 
our communications and other business bases. This 
view of the world has helped people become part of 
the bigger picture — they see themselves as a conduit 
in tapping new technology for the corporation. You 
can feel the difference, a sense of excitement in 
Sunnyvale that didn't exist before. 
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Inspecting the chips. 


What is your vision of future design technology using 
extensive VLSI? 


DG has always been in the forefront as far as in- 
corporating advanced semiconductor technology in 
its systems. As we move more and more into VLSI 
and ULSI, I see a closer coupling of systems and 
semiconductors. CAD should be a significant medium 
in facilitating this. Soon the R & D community will 
be brought together with a comprehensive CAD plat- 
form — workstations connected to databases via 
high-speed communications media. It will give de- 
signers an excellent set of tools that tap into a library 
of building blocks that they create. 


Are there any further improvements, any goals you'd 
like to see Sunnyvale achieve over the next year? 


I'd like the development organizations to be very 
demanding of Sunnyvale, to pin us against the com- 
petition in terms of capability because that's how 
we're going to get better. Constant pressure from the 
outside will keep us improving. At the same time, 
however, I don't see us as a funnel for every project 
the company undertakes. We're not in this to take 
business away from the outside world and bring it 
into Sunnyvale, but to act as a knowledgeable re- 
source for making the right technology choices, a 
development center that helps transform systems into 
silicon. 


So we want to keep this very fast throughput ca- 
pability and continue to improve it — not clog up 
the factory with production — that's what DG needs, 
and it puts us in a noncompetitive but catalytic po- 
sition with our vendors. We are moving our process 
design and CAD technology into leading-edge very 
rapidly. On top of that we are working on a major 
new processor development. | think Sunnyvale is in 
a good position now to contribute to the greater 
R & D community: we've got a lot of technology 
know-how, good people, and we keep getting better 
and better. We're now part of a continuum of ex- 
pertise at DG — from the system design all the way 
down to the chip. That's probably our most significant 
accomplishment. 
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“Imagine designing a factory from the ground up, with no constraints whatsoever. Imagine building it 
in the middle of a cornfield: plowing the field, and planting an automated factory in its place.” 


FIRST HARVEST 


This was the philosophy that seeded Cornfield, a project to automate Data General's manufacturing process. Over a 
period of years the engineers of Advanced Manufacturing had worked with hundreds of vendors and as many in- 
house technologists to implement the latest production techniques with state-of-the-art machinery. Now, in March, the 
Portsmouth facility was ready for operation, and by the end of the year Data General would reap its first harvest: a 
system that assembled, fabricated, and tested printed circuit boards with renewed efficiency, and without which the 
new product line could not have been produced. Here we tour the manufacturing facilities with the director of Advanced 
Manufacturing and Technology, who first envisioned Cornfield and directed its implementation. 








Cornfields for printed circuit board fabrication are in Clayton, NC (left) and Singapore. This is where the fabrication of the printed 
circuit board is done — the artwork, the creation of the etches on the layers, the location of drill holes, the physical routing; and 
the net list is electrically tested at the bare-board level. 





Cornfields for printed circuit board assembly are in Portsmouth, NH (left) and in Apex, NC. Here individual components are 
inserted on the boards, then verified before going to wave solder. 
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“Nobody's using a process like 
ours. We believe this is the right 
way for our business niche. At Data 
General, where we build relatively 
modest volumes of a wide range 
of part numbers, there's a high 
premium on rapid turnaround, on 
rapid introduction of new designs, 
and on preventing defects. We op- 
timized for those goals." 


“Cornfield has tested our ability as 
systems integrators. We integrated 
Data General software and hard- 
ware with equipment from over 20 
vendors. The assembly systems are 
all controlled by MV/10000s. In 
Clayton, the data for all the art- 
works to run the laser photo plot- 
ter, the data from the drills, and 
the data from the bare board test 
will be stored in a 4-gigabyte 
DG/SQL database." 


FABRICATING THE BOARDS 


Increasing Board Densities 

















An example of artwork used for the ECLIPSE MV/20000 and ECLIPSE 
MV/2000DC, our densest boards to date ... 


.. And an example of what's happened to our artwork over the last four 
years: from low density (left), to medium (middle) to very high. The criterion 
for a board's density is how many lines you can put between the pads. 


It takes about 8 to 13 of these artworks to fabricate a board; you develop 
the circuits on layers of copper-clad fiberglass, laminate them into a sandwich, 
and drill and plate the holes to make all the interconnections. The accuracy 
of this process must be better than .006 across 15 inches and 13,000 holes. 


This is the old way of making photo plots — essentially a pen plotter. It had 
little wheels, light, and would index to the right-sized light. Then the table 
would move around — we had those in Southboro. 


The photo plots were sent to Clayton 
and stored in files. When it was time 
to start the job, a copy was made from 
a glass master. But the mylar films would 
distort and get damaged and it took 
time to make a photo tool setup. The 
copy had to be checked manually. And 
all that work increased the setup time, 
which increased the batch size, which 
increased the lead time. 


This is the new way of doing it — a laser photo plotter. The laser makes a 
raster image of the photo plot based on the visual data. So as you're building 
a job, you're also making a photo tool for that design; and this machine is 
accurate enough to accommodate today’s fine-line boards. 


Making Images of the Inner Layers 


Meanwhile the inner layer core boards have been stored on palettes. Now they're retrieved from the warehouse 
by a computer-controlled truck that picks out the correct one. The job is delivered to the beginning of the line where 
it's not touched by human hands until it's a developed inner layer. The boards are cleaned, dried and coated with 
liquid photo resist. Then a photo tool is mounted on the exposure machine and UV light creates the image on the 
board. Some chemicals are applied, it's flipped over and the same thing is done to the other side. Then it goes 
down a chemical processing conveyor and comes out a finished inner layer photo circuit. This process is repeated 
on all of the inner layer cores necessary to make a particular pce board. 
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The old way of creating the image on the photo resist required a lot of 
manual intervention. This is how the inner layers used to be built. Operators 
loaded the photo tools, loaded the work on and off, and it was subject to 
damage. There was a lot of work-in-process inventory waiting, a lot of work 
queuing up before it was plated. 


After the inner circuits are done, they have to be inspected. The old way of 
doing it was to have someone with a magnifying glass look at the layer and 
find the defects. Of course they made mistakes, and they couldn't do the 
fine-line boards. If you make a mistake and laminate the boards together, 
the finished board is no good. 


So this machine inspects the board au- 
tomatically — lights it, scans it, and 
digitizes the data. Inside its computer 
system it looks at this picture and finds 
the defect — in this case a broken line. 


Each layer of the pe board goes through a black oxide chemical process. 
Then it used to go to a lamination press, where under heat and pressure it 
would be squeezed into a bonded sandwich. 


Now, instead of using hydraulic pressure, we use a vacuum to squeeze the 
boards together. It makes a much flatter, more consistent design, with less 
shifting of layers. 


The boards are x-rayed to ensure that the registration shift is within limits, then they're drilled. The drilling data 
used to be on mylar paper tape; now we're implementing optical fiber links to load data into the machines from 
magnetic diskettes. And a large-disk database will manage all that data. 


After the drilling, the board is plasma-etched to clean out the holes. 


The Outer Layer Process 


This construction site will soon have the same integrated material handling 
system and automatic load/unload stations with photo-plotted artwork to do 
the whole outer layer process the same way we do the inner layer. The outer 
layer process includes laminating the photo resist image, developing the etch, 
stripping, applying tin lead, hot-air solder leveling, applying gold fingers, 
then routing. 


After the board is routed it goes to test. In the past boards were tested against a known gold board, but problems 
occurred when those boards differed from the design or got damaged. The tester we're implementing now will let 
us build fixtures rapidly and test them against the database. Fixtures are a bunch of little pins that translate the 
49,000-pin standard grid of the tester into the grid we want to test on the board. 
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“Sometimes the machine we 
needed didn't exist — we had to 
convince vendors to try new de- 
signs or to change an existing one. 
We would say, ‘If you design it this 
way we'll buy it, and we think we're 
a good example of how things 
ought to be designed. Design it 
to satisfy us, and you'll probably 
satisfy a lot of other people.’ 
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“Cornfield tested us, and the new 
products tested Cornfield. It is 
generally conceded that we would 
not have been able to do the new 
products with their denser boards 
if we didn't have this system. With 
all the revisions and engineering 
changes we had to go through, 
and all the new artwork re- 
leases — it would have taken a 
lot longer to turn them around." 





ASSEMBLING THE BOARDS 


Old Assembly Procedures 





All of these things had to come together to assemble a printed circuit 
board — fixtures, different kinds of components, instructions, and so on. 
People had cabinets full of information and procedures for doing things. 
Inventory was locked in a warehouse and had to be retrieved. 


Work in process waited in antistatic bags. People operated the machines and 
would have to load the boards on and off. Here two people are checking to 
see whether the boards were assembled correctly. Then the boards would 
wait to go to wave solder. 





_ That's all changed now. In Portsmouth 
Wwe] cond Apex we have an automated stor- 

4 age and retrieval system [ASRS]. This 
wall is 300 ft. long, 17 ft. high, and has 
machines on both sides. Inside we store 
all the component inventory, along with 
work in process as it's being moved 
automatically from one workcenter to 
the next. 








The automatic storage and retrieval system handles a magazine containing 
10 standard-sized panels. 





Inside the automated storage and retrieval system you can see these pigeon 
holes, about 17,000 of them. There are two railroad tracks with two trucks 
that run on them and index up and down, picking things out of those storage 
areas. 





The magazine comes into the workcenter, moves up an elevator, and transfers 
the boards onto this machine. Components are inserted, the boards are placed 
in an empty magazine, and the magazine goes back into the ASRS. 
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Before Cornfield we used to assemble a pc board by kitting all the different components for the board, moving 
the kit to a machine and setting that machine up. Now that we have enough machines to handle every component, 
all we have to do is move the magazine to the right machine and tell it to insert the components. No more kitting 


and setup. 


This is a closeup of the insertion heads. Traditionally the biggest defect in 
going from manufacturing to test was wrong, missing, or reversed components. 
It used to be a lot of trouble to detect those errors and fix them. Now, with 
electrical verification technology right in the insertion head, we can verify 
that it's the right component and that it's not reversed before we insert it in 
the board, 





Sometimes, when components are automatically inserted into the holes, the leads get bent. That's a very difficult 
defect to find and it can cause intermittent problems. So another machine inspects the lead insertion — optically 
scanning the bottom of the board to ensure that the leads have gone through the holes correctly. 


Finishing Up 


Then the boards go to a computer-controlled wave solder machine. 





This machine separates the boards after they've been assembled. 


Dw oe 
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System Integration 


Now we're coming down the home stretch — systems integration. This is 
Apex, the plant that does system integration for the MV/2000DC. After the 
printed circuit boards are built we can rapidly flow them right into this 
technology. The lead time in assembly used to be several weeks; with Cornfield 
we can make it a few days. 


A YEAR IN DEVELOPMENT 








“The capacity and short cycle time 
in Portsmouth allowed us to build 
the boards quickly, verify all the 
components, and keep workman- 
ship defects from getting into test. 
We went from bare boards to as- 
sembled boards to integrated sys- 
tems in an impossible time frame. 
That couldn't have happened un- 
less Cornfield was in place." 
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A HOUSE 
RAISING 





In the early spring, Edson deCastro led a small party across a still-frozen stretch of land in Durham, New Hampshire. 
Then, with shovel in hand, he performed a ground-breaking ceremony for the new development lab that would eventually 
be raised there. What was exciting about this occasion wasn't the site itself, which was leveled flat; or the proposed 
facility, which was neatly laid out in blueprints; but the research into mass storage technologies that would go on 
here — some of the most advanced research in the country. 


To learn about this facility we visited the division director of Mass Storage Engineering and the manager of the 
Advanced Technology Department, shortly after the group had moved into its new home. In the following interview 
they described the adventure of breaking new ground, both on the land and in the lab. 





[To Joe, director of MSE.] Could you give us a 
portrait of this new facility and tell us how the move 
came about? 


We looked at many sites in New Hampshire — Dur- 
ham was considered to be the best one. This is an 
attractive place because it's accessible, and of course 
the University of New Hampshire is here. With about 
10,500 students and 90 buildings, UNH is a fairly big 
operation in town. 


We were one of the first industries to come to Durham. 
It took a lot of hard work between the Data General 
real estate group, corporate construction, and the 
people of Durham to make this happen. The new 
facility was built on a parcel of land of about 150 
acres that used to be an old sawmill area. The 
completed building consists of 300,000 square feet, 
100,000 of which house the R & D area we share 
with the Volume Products Division. 





We knew the Durham facility wouldn't be ready until 
September, so because we wanted to hire people in 
the meantime, we decided to rent a temporary space 
in nearby Newington. That way our employees would 
not have to relocate again when the new building 
was ready. We also wanted our employees and their 
families to be able to make the move without dis- 
tupting their children’s schooling. We're just now 
moving out of Newington into the Durham facility. 


It's been quite an adventure. When we announced 
we were going to do this I told the lab as a group 
that it would be like starting your own company, but 
with a billion dollar corporation behind you. For most 
people the chance to build a startup venture only 
comes once in a lifetime. I wanted this to be well- 
recognized as a professional lab; well-respected in 


the community, at the university, and within our 
profession for the engineering disciplines that we 
represent. And | wanted that recognition not only in 
the state but in the country and worldwide. So we 
needed the best people, and the best equipment. If 
we were going to do this we wanted to do it right. 





When I decided to move up here | hoped that a 
critical mass of our designers would come with me. 
I talked to each member of my staff individually, as 
well as with the managers under them who represent 
the whole lab, and told them my ambitions and 
goals — what I thought this place could represent. 
Two things happened from that encounter: the group 
came to feel real ownership of the lab — this is our 
lab — and we developed a bond between managers 
and staff. As a result, over 60 percent of our lab 
moved up here. As a development organization we 
started off on the right foot. 





Today we've got a class A lab with the best equip- 
ment, as promised. | think that Ed [deCastro] and 
Bob [Miller] bent over backwards to make this go. 
Each of my section managers was given the authority 
to specify his own development lab and request 
whatever equipment he felt was needed to make this 
one of the world's preeminent R & D facilities. For 
example, Don, who manages our advanced tech- 
nology area, has some equipment which would nor- 
mally be found only in university research facilities. 
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[To Don.] Can you tell us about that? 


Yes, our lab is rather unique within DG in that 
respect. One of the devices Joe's referring to is a 
magnetic characterization stand that was built to DG 
specifications — it took a year to build and cost 
several hundred thousand dollars. It was installed in 
Newington where we used it for nearly a year, and 
then had it moved here. As a matter of fact, from 
the day we took the system down ... it was functioning 
one day and four days later it was functioning again 
here [in Durham], and that included moving a 3,000- 
pound granite slab with optical equipment on the 
top and bottom. 


We use this system to investigate media of almost 
any size or shape. It can spin media from 3.5 to 14 
inches in diameter. We can find any region on a 
disk that's spinning at 8,000 RPM with an accuracy 
of about a tenth of a micron, and we can investigate 
its magnetic properties. So it's kind of a special 
instrument. 


Another unique instrument is our vibrating sample 
magnetometer. This device allows us to take a piece 
of media from a data recording device and inves- 
tigate the properties of a small section of the film 
where information is stored. We can literally punch 
out a small sample, vibrate that sample up and down 
in the presence of a large magnetic field, and extract 
the total magnetic information of that sample. We 
can measure its resistance to stray magnetic fields 
and predict its performance characteristics — how 
many bits per inch we can store, what the quality 
is of that media, a number of things. 


Those are some of the more special pieces of equip- 
ment we have here. 














[To Joe.] And the engineering support and services 
.. they're shared by all the groups at the Durham 
facility? 


Yes, it's under one group for all the tenants 
here — the release group, the computer center, PC 
layout, the machine shop. By next week we'll have 
16 McAuto stations, the best tools for mechanical 
design. The machine shop is exceptionally well- 
equipped so we can build prototypes quickly. And 
the computer center is as big as a basketball court 
— it's the best center you can imagine. 





Earlier I noticed a group of UNH faculty members 
touring the facility. How is the relationship with 
UNH progressing? 


We've spent a lot of time with the people at the 
university, trying to build a close cooperative rela- 
tionship between our development programs and their 
engineering. Last year five of us gave lectures on 
campus that were very well-attended by their faculty 
and students. A lot of our engineers are taking courses 
at UNH, and we're helping them in growing their 
engineering area. 





I would imagine you have quite a bit to offer them 
in the way of knowledge and experience — I've 
heard a lot of praise for the work you've been doing 
in the Advanced Technology lab. [To Don.] Can you 
talk about some of your research? 


In general we've been studying two fundamentally 
different ways of storing data: one is what's referred 
to as Winchester disk technology; the other is optical 
data storage technology. Our lab is probably at the 
leading edge of what's going on in those two worlds. 


In today's products using Winchester technology, the 
highest aerial storage density, data access time or 
data transfer rate available at any price is from IBM. 
They're storing information at 24 million bits per 
square inch of media surface, they're transferring 
data at 3 million bytes per second, and have an 
access time that's below 20 milliseconds. 





In our research lab today, we are storing and trans- 
ferring information at up to twice the density and 
data rate currently available in the marketplace, with 
access times significantly faster. 


These improvements are possible because we've gone 
to the outside world for components that are unique 
to Data General. The recording channel we have is 
a DG invention the channel architecture and the way 
we handle recording wave forms are unique in the 
industry; and the magnetic components themselves 
are unique. The recording components we use were 
made expressly for Data General under joint devel- 
opment agreements with suppliers of thin-film re- 
cording heads and thin-film media. 


So in Winchester disk technology we've demonstrated 
almost double the current capabilities. Now we're 
working to increment that even further through joint 
development and sponsorship of programs at several 
universities. We have a program with a magnetic 
technology center at Camegie-Mellon University, 
we've sponsored directed research at Boston Uni- 
versity, we've worked with the University of New 
Hampshire, and we've presented papers at the In- 
ternational Magnetics Conference, the Magnetism and 
Magnetic Materials Conference, and the CMU Con- 
ference on magnito-optics. So we get out in the world. 


We're also making progress in the optical area. Again, 
no matter what size your checkbook, you'll find that 
write-once optical storage media is all you can get 
today — you can write your information but it can't 
be altered. A few people think that's an advantage, 
but almost everyone else would prefer alterable mag- 





netic storage. The major reason is that optical storage 
is expected to be available at a much lower cost 
than Winchester technology; as low as $1 per me- 
gabyte stored, compared with the $10 per megabyte 
that Winchester technology can provide today. 


In our research lab we can demonstrate data storage 
into the hundreds of millions of bits per square inch 
of media surface using optical technology. We're 
transferring data at about a million bytes per second 
and we've done read-write-erase demonstrations on 
media. We've been doing this kind of work - meas- 
uring both bit-error rates, bit-error lengths and char- 
acteristics of multiple sources of erasable optical media 


A YEAR IN DEVELOPMENT 


- for some months now, and we've been getting stable 
consistent results. 


So, you could say we're pushing the state of the art 
forward in the mass storage technology arena. 





That brings up an interesting point — about keeping 
the lab visible to the rest of the R & D organization 
and integrated with other development efforts. [To 
Joe.] Are you finding that difficult as a remote site? 


No, but it does require more work on our part to stay 
connected with all our constituencies. Besides on- 
going relationships with vendors and professional 
associations in our engineering field, there's a re- 
lationship with the town and the university to be 
continually developed and maintained; and we want 
to make sure we stay close to our co-tenants in 
Volume Products — we can't afford to have the house 
divided. 


Of course, the corporate support we've received has 
been extremely encouraging to the engineers. They 
see that we're not going to be off on our own and 
forgotten in some remote outpost. I've mentioned this 
to Tom [West] and have encouraged people to come 
up here. The exchange will help my people feel 
they're part of the company, and it will show others 
that we're developing leading-edge technologies that 
will provide a very valuable resource. We're also 
planning an open house next spring with the town, 
the governor and the university — the more people 
we can tour through, the more we expand our contact 
with the rest of the world. 


In the end I think there are three important aspects 
of this business: your reputation in the past, what 
you're doing today, and what you're investing in for 
the future. My level of future investment as a portion 
of the total lab expense is quite high. But in the long 
term that's where you end up winning — being a 
leader in new technology. 
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Boston Marathon 
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Manufacturing holds 3rd Technical Symposium; proposal for application 
of laser photoscanning to semiconductor testing receives first prize. 
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IT’S DEVIOUS 


In the past, the connection of minicomputers in networks merely required that an operation could be performed remotely 
if necessary. Products like XODIAC running on AOS/VS or DECNET running on VMS introduced a limited form of 
distribution between systems, where each possessed its own private resources but allowed some of them to be shared 
— provided you knew where they were and how to access them. This kind of distribution allowed a measure of privacy 
and control that was, and continues to be, useful in corporate-wide networks. But as companies began to automate 
at the department level, the benefits of being able to share printers, disks, terminals and data — freely and transparently 
— became clear. 





In April, a handful of software developers began to demonstrate this ability in the lab. Their goal was to build a 
superset of AOS/VS whose unique feature was a mechanism for distributing resources, transparently, among a community 
of workstations on a LAN. When asked how this mechanism worked, one of the designers is said to have replied, “It's 
devious.” Some say this is how the project — codenamed Devios — got its name. In the following interview a Devios 








development manager explains the distribution function to us in a little more detail. 





What are the important aspects of distribution? 


The value that Distribution brings to the party is an 
ability to take collections of machines and allow the 
users to share parts of what they have on their system 
— whether it's files or disks, tapes or terminals or 
printers — in a way that's a natural extension of 
what they'd see on a single system. 


What Devios did, and what's exciting about it when 
you talk to real users as opposed to developers, is 
that it allows you to take five or six machines and 
get the incremental value in computing power of 
systems added. Rather than needing a copy of PINK 
[a popular in-house text editor] on every machine, 
a department can now have one copy that everyone 
runs. They can cut down on the number of copies 
and do some fairly fancy things — stuff they've 
wanted to do but couldn't before because they needed 
five copies to cover every machine in the department. 
And once all the toolbox directories are in one place 
where everyone has access to the latest rev of the 
compiler or the latest rev of the editor, there’s no 
more confusion as to what copy is the most recent. 





Devios realizes some of the benefits we all thought 
there could be if machines and networks were con- 
nected in an easy-to-use way. 


What were the challenges in development? 


For those of us who worked on the distribution phase, 
it was that our functions had to be completely in- 
visible. It's hard to explain to someone what distri- 
bution means in the same way you can talk about 
what process scheduling means for example, because 
you can sit at a terminal, do a hook, and say ‘OK, 
I understand what processes are.’ 





We provided a couple of pieces that users see: new 
CLI commands, the new directory structure and name 
registering — the colon colon [::] that people talk 
about. But most of our work was done inside the 
system — things that let you get to the LAN without 
having to run Xodiac, things that let you get from 
one machine to another. So the other programmers 
working on the operating system could make their 
components work by talking to us rather than having 
to rewrite all their code. 


It's difficult to describe what we've done except in 
terms that make it sound very trivial. The reality is 
that we put in weeks of work to bury our function 
underneath other layers of software so nobody could 
see that we'd done anything. If it worked then we'd 
done our job; if it didn’t, we were the first people to 
go off and look at what broke. 
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Did the distribution aspects of Devios cause any 
particular problems for programmers during debug- 


ging? 


One of the hard parts of debugging the system is 
that when one machine experiences problems it fre- 
quently triggers fallout on two or three other ma- 
chines. So when you want to understand why one 
machine hit a system panic you have to look at, in 
this particular case, what fourteen other machines 
were doing to find out which caused the problem 
and why. This presents some great intellectual chal- 
lenges and occasionally some physical ones as well. 
It makes the whole process of fault isolation and even 
management of resources very difficult because you 
have to decide where to start looking. You actually 
have to find 20 users and ask them what they were 
doing; it's not as simple as watching a single machine 
fall. We're often involved in trying to diagnose fairly 
complex situations where there are side effects or 
chain reactions going on across several machines at 
the same time. 
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Another strange thing about something like distri- 
bution is that you lose your faith in the primary beliefs 
you have as a programmer. You've always known 
that on one machine nothing can ever really happen 
simultaneously with anything else -- it just can't be 
done. But now, on two machines that talk to each 
other, that's no longer true: you really can have two 
things start at the same time. It's a real surprise the 
first time you find out that these things tried to happen 
simultaneously. There are things you know firmly, 
like there's no such thing as parallelism (laughs). And 
yet the very first thing you find out, the first ugly 
bug you have to look at is, ‘Wait a second, someone 
tried to do something at the same time I'm doing 
something — it can't be.’ That's one of the strange 
things about distribution that you don't see any place 
else. 





You passed that phase, the debugging, some time 
ago? 


For the most part we were through coding and de- 
bugging, especially in the distribution world, over a 
year ago. The tough part now is actually going out 
and supporting a 5-, 10-, or 20-machine scenario, 
seeing what real users do when they beat the thing 
up. We're trying to find more complicated ways of 
putting machines together to see what they'll do to 
each other. 


How do you get that information? 


We have communities of networks scattered around 
the company — in groups as diverse as software 
development, CAD tools and manufacturing. The 
communities range in size from just a couple of 
systems up to 16 workstations on a net. They are our 
unfriendly alpha test users — they are paid to be 
unfriendly! (laughs). 


So they feed back all their problems to you? 


Oh yes (laughs). One of the nice things — and it 
really is — about people who use each other's soft- 
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ware and hardware is that since you're just upstairs 
or downstairs it's merely a matter of leaving a note 
on someone's chair to come down and look at what- 
ever died. So you get an expert opinion within an 
hour of what went wrong, and know what you should 
do about it. It's being done in a formal way, as alpha 
[internal] test sites, so there's a responsible group 
tracking system behavior and how we close out bugs. 
Besides wanting to use it for their own purposes, 
these groups are part of a test process that lets us 
get a feel for whether we're making progress. 


This phase for a new operating system is long and 
laborious. What sort of effect does that have on the 
developers? 


It's most difficult when you're in the dark and dismal 
stages of first starting out beta [external] testing and 
you run into the things that show you where problems 
are. You get your first set of customers who are 
expecting that they can take the manual at face 
value, as opposed to the SQA people who are some- 
what sensitive to the fact that things may not be as 
stable as all that. That's the point where it's darkest 
before the dawn — when you first see the ‘I didn't 
know that was broken’ kind of bugs. You reach this 
point in any project, where it's clear that things are 
not as good as you thought they were. 
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Then there's the early adolescence of getting a first 
revision out. This has all the growing pains and 
associated pitfalls of trying to get everything done 
all at once. Through experience you develop a dif- 
ferent expectation of what it takes to get through the 
tough spots and what they'll look like. On every 
project you go through a period where, every time 
you fix something, you find something else that doesn't 
work. There's a gallows sense of humor amongst 
development groups, and | think a part of that is just 
knowing that you're going to go through that stage. 


Once you realize that it's just part of the cycle, it's 
not so bad. But it's a lot more frustrating if it's the 
first thing you've ever built. When you're seeing it 
for the first time and there's no one to tell you that 
it always happens, it can be very discouraging. 





What groups are involved in this project? 


The core group is in operating systems development, 
of course. In addition a significant number of people 
from the communications software development group 
have been heavily involved. An then there are the 
support folks from SQA and CSS. 


Were any new hires involved? 


Yes, quite a few college hires were involved. 


How did you deal with that? 


Gray hair (laughs). You got old faster. For the new 
college hires it's been very exciting — to get in on 
the ground floor, at the beginning of their careers, 
of a new development project. But it proved chal- 
lenging. Those people brought a lot of enthusiasm 
to the project, it was an opportunity for them to cut 
their teeth on real new work. And it was an exciting 
project in terms of what others were doing in the 




















marketplace. The enthusiasm has, in many ways, 
outweighed any detriment from lack of experience. 
It overcomes a lot of things when you're willing to 
take a second shot at something after your first at- 
tempt doesn't work the way you thought it would. 


Did you find that the enthusiasm of the new hires 
rubbed off on the people who had been around for 
some time? 


Yes, but you have to understand that the rest of us 
average somewhere over five years’ experience, so 
we're used to Data General (laughs). But yes, it's 
easier to catch enthusiasm when there's a wave of 
it around, and the new hires certainly helped. One 
of the reasons we could do it was because there was 
a good mix of skill levels: we had enough maturity 
around to say ‘Here's how to shortcut,’ whereas it 
could have taken a couple days without that help. 
That doesn't mean going off and doing the learning 
part for someone. You don't get rid of all the head- 
scratching, but it's easier when you have enough 
people around who can pass on the kind of knowl- 
edge that you can only get by redoing someone 
else's hard work. I think we did a good job there in 
terms of transferring that kind of understanding. 





Do you think that some of the new college hires 
who worked on this now have enough experience 
to go on and take a leadership role on another 
project? 


Quite possibly. What we're doing within the orga- 
nization is to have those people participate in a sort 
of buddy system for new hires — either with next 
year's college hires or some experienced hires — to 
help bring those people up to speed. It's a leadership 
role in a one-on-one situation. 





Having worked on Devios and gotten a solid sense 
of what the development process means, some of our 
recent hires are now ready to define how they want 
to participate in the next project. And that's really 
exciting. They've taken a step in maturity that's usu- 
ally tough — they now want to participate as opposed 
to just absorb. 
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There's a point in many peoples’ professional de- 
velopment where they spend a couple years waiting 
for people to tell them what they ought to be working 
on. Yet a lot of our people, after only a year, want 
to take responsibility and have input into the process. 
They have the information and the skills and the self- 
confidence to offer worthwhile opinions. And they're 
being listened to. 
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DARLING, 
-—— YOU LOOK 
8 MARVELOUS 


In April, while the workstation hardware was being built, several important technologies were being coded and 
debugged in software development labs at Westboro and RTP. One of these was the AOS/VS windowing subsystem, 
involving several layers of software whose combined purpose was to integrate the workstation's presentation services. 





In talking to the project leader, one thing that emerged was the fact that, under the rubric of workstation development, 
there was more cross-fertilization and interdependence going on in R & D than ever before. The other was that, with 
computers, it's not just how you feel but how you look that counts. As this notion gained credence, developers got 
serious about windows and graphics, started looking at them in context of the whole system — and discovered that 
building them into the product line involved a lot more than cosmetic surgery. 


i 


Windows seem to have come into the vernacular as 
a general way of talking about user interfaces ... 
yet the specific implementations can be quite dif- 
ferent. Can you explain what windows mean in a 
DG context? 


That's the first question we had to ask ourselves when 
we started out. None of the people on the software 
side really had any familiarity with windowing and 
graphics. We'd all been brought up in the DG way: 
doing things as asynchronous terminals and com- 
mand line-oriented interfaces. So we had to figure 
out what windowing and graphics really involved. 


At the most basic level windows provide a way to 
simultaneously run several tasks on a bit-mapped 
graphics monitor. Each task exists in a separate 
window, and the user can have any number of win- 
dows open on the monitor at the same time. Beyond 
that the style and features of windowed products can 
vary enormously, so we looked at different vendors’ 
equipment to get some hands-on experience. 


We went to trade shows and looked at what was in 
the marketplace from Apple, Sun, Appollo and IBM, 
as well as other vendors. After evaluating their 
strengths and weaknesses and making some basic 
decisions about windowing and graphics for our 
product line, we had to go off and do it — and try 
and do it quickly. (laughs) It was a major challenge. 


How did the development effort proceed? 


There was a core group of people working on the 
windowing subsystem. It was designed to be a com- 
mon component that would fit into multiple operating 
systems. That group did most of the investigation and 
the initial definition of what we were going to do. 
Then they started on the design of the pieces and 
began working with the operating systems groups 
to figure out how to make this component fit into 
AOS/VS, AOS/DVS and also Unix. Subsequently, as 
industry trends became more clear, the Unix group 
decided they should implement a standard window- 
ing package. 


One of the major goals of the windowing effort — 
and windowing was designed for the bit-mapped 
graphics display on the DS/7500 — was to have 
existing applications run in that environment without 
any modifications. These applications were designed 
to talk to our standard async terminals, or dumb 
tubes, as we call them. Now they also had to be 
able to talk to the windowing subsystem, but to ask 
people to modify all the DG and customer applica- 
tions would be unthinkable. 


Our solution was to build a terminal emulator — 
software that emulates the functionality or capabili- 
ties of the D460 terminal. Applications could then 
issue a ?Write, for example — a system call issued 
to do output to the terminal. Normally that would be 
sent via an async line to the display, but in this case 
it gets sent to the operating system. The operating 
system device drivers were modified to talk to the 
terminal emulation software. So the software takes 
these characters and turns them into GIS instructions. 


In this way we were able to have applications that 
didn't know anything about graphics actually doing 
graphics and windows. That was the first part of it. 








The second part was to take applications that were 
modified and enable them use multiple windows, 
graphics and pointing-device interfaces. To do that 
we developed a whole new set of system calls to 
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support windows: to create and move them around, 
hide them and delete them. These applications also 
had to accept input from a pointer device, or for 
tracking a cursor around on a screen. 


The technique for developing the set of new system 
calls was the windowing subsystem. We integrated 
the windowing subsystem into the operating system. 
In AOS/VS the system calls were integrated into a 
component called PMGR, which is where the rest of 
the asynchronous device support is. 


We also needed to provide a way to do graphics 
within windows. The most primitive way is GIS, which 
is implemented in hardware. The limitation of GIS 
is that it's designed to be used with assembly-lan- 
guage instructions, so if I'm writing a FORTRAN 
program it won't work. So we built interfaces to get 
to the GIS instructions from FORTRAN, COBOL, 
PL/1 and so on. A group in RTP designed a sub- 
routine package called GI, which contains routines 
for each of the GIS instructions like Draw Line and 
Draw Character. On top of that they built more so- 
phisticated commands like Draw Circle, which is 
done from a set of Draw Line operations. Our inten- 
tion, if Draw Circle becomes a popular operation, is 
to migrate it to become a GIS instruction. But for 
now it's done through the GI subroutine package. 


Eventually we also implemented GKS, an industry- 
standard graphics package. It provides industry- 
standard interfaces and things like scaling of images. 
But it doesn’t provide the same performance as Gl, 
which is tailored to GIS. 


The last major software initiative was to build an 
applications platform. The CLI serves as a platform 
of sorts in that you can execute programs from it 
and perform all kinds of operations. But the platform 
DG is really interested in is CEO, because it inte- 
grates applications like word processing, electronic 
mail, calendars and spreadsheets. We wanted to 
build the same kind of platform for the windowed 
environment to manage menus, pointing devices and 
graphics. 


—————— 














The first thing we did was build a CLI-like piece 
called DG/View. We liken it to the CLI because, 
in the same way the CLI gets you to system calls, 
DG/View gets you to the system calls that do win- 
dowing such as Create Window or Move Window. 
And it allows you to do that in a graphics style — 
you point at things, pull down menus and select 
menu items, instead of typing commands on the 
keyboard as you would in the CLI. 





The second piece is the ability to bring up appli- 
cations and create menu items that let you integrate 
your own applications and build a tailored environ- 
ment. We also designed one application to go into 
that environment: an electronic mail application which 
is now window-oriented. Like CEO, the electronic 
mail package has an inbox that displays your mes- 
sages. The difference is that instead of typing com- 
mands to say which one you want, you point at 
them — the interface is a graphics environment. 


So those are the pieces we've provided for our cus- 
tomers: the emulator, graphics system calls, graphics 
subroutine packages, and then the platform for build- 
ing applications. Now our customers and ISVs can 
build applications to fit into that platform. The 
TEO/Electronics package is an example of that. 





If we acquired a software package could it simply 
run in the window and coexist in that platform? 


That's right. You would want to modify your appli- 
cation to take advantage of the graphics primitives 
we provide, but industry-standard GKS would be 
pretty straightforward. If you use someone else's 
hardware-level drawing, then you would need to 
change that to use our drawing capabilities. 


So the product offering starts with the primitives 
and ends up with an environment. 


Yes. The piece we don't have is a complete set of 
applications; that's why we provided the environment 
for the applications to work on top of. 


How did the interaction go between the core group 
and the dependent groups? 


I would say pretty well. Initially there was some 
friction because people weren't used to thinking of 
windowing and graphics. They had other responsi- 
bilities involving getting out the MV/2000 and the 
MV/20000s, and this was one more thing they had 
to do. There were some new details also; this was 
a single-user environment and they were used to 
working with multiuser environments. So they had to 
adopt a new kind of thinking. 


But soon people got quite interested in the project; 
windowing and graphics are exciting technologies to 
work on. They worked closely with us in defining the 
system call interfaces and in getting all the pieces 
to mesh. Overall | think it went really well. It was 
challenging to have DG/View, the GI, the windowing 
subsystem and the operating systems’ people all trying 
to work together on this project. The coordination was 
very successful. A key to that from my perspective 
was CEO. It provided a way for all of us to com- 
municate effectively even though we were scattered 
across many locations and working different hours. 





What sort of testing was done? 


The windowing effort required field input; we needed 
feedback from people who had real graphics appli- 
cations, which DG doesn't develop itself. We had 
several customer test sites that we provided with 
prereleases of the software. The Corporate Systems 
Support [CSS] organization was extremely helpful in 
this phase — taking the preliminary products, pack- 
aging them up and sending them off to those test 
sites. CSS also answered customers’ questions and 
gave us feedback so we could actually go in and 
make changes. In certain cases we changed some 
of our system call definitions because a customer 
would say, ‘Well that's fine except ...'. Again, because 
we weren't that familiar with the graphics and win- 
dowing environment when we started, we made some 
mistakes. So this feedback was critical in making it 
a usable product — a product that really met the 
customers’ needs as opposed to one they'd have to 
work around. 
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Where were the test sites located? 


All over the globe. We had test sites in Australia, 
England, Minnesota, and several in Japan. Nippon- 
Data General [NDG] was trying to take what we 
were doing and modify it to support the Japanese 
marketplace. They were also working with their cus- 
tomers to be sure the product met their needs. They 
had several large customers with DS/4000 series 
workstations who were very interested in the 7500 
series. It's the closest work with NDG that I've been 
involved in. Again, CEO was really beneficial in that 
environment: I'd come in each morning and there'd 
be 12 messages from Japan (laughs) as well as some 
from RTP. 


It wasn't an easy task by any means. Normally when 
you do this kind of field test of your product, you set 
up sites that are close together. Ours were scattered 
all over the world. It was quite an amazing effort. 





And the systems engineering people managed the 
geography and the data? 


Right. They got the revs out, making sure that all the 
sites were at consistent rev levels, and they coor- 
dinated incoming problems so we could address every 
issue. 


That sounds like a nightmare ... 


It was (laughs). But it was absolutely necessary for 
the quality of the final product. 
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The evolution of the computer as a tool is still recent enough that, while some people have used it for decades, there are many 
more who never have. From thirty thousand feet that probably appears obvious; but inside a company like Data General, where 
computers are so indigenous that every worker has a terminal, such a dichotomy of experience is difficult to imagine. Years ago 
DG had ceased being able to drive large pieces of its operation manually. By now, the notion of using computers to build 
computers was axiomatic, and the development process was wholly dependent on it. Nowhere was this better understood than 
in Engineering Services, in April, when submission packages for just about every machine in the company started pouring in. 


The group is something of a crossroads between development and manufacture, where an engineer's logic design is transliterated 
into data: specifications for the placement of components, the paths of the etch, the layers of the PC board, and a thousand other 
details required to build a real, functioning machine. The data is produced by hardware and software tools, many of them either 
designed or acquired and maintained by the Engineering Services group. This time, however, it was the heroics of individuals 
rather than tools that kept the sheer quantity and complexity of data from bringing the process to its knees. In the aftermath of 
this effort, the director of Engineering Services gave us some useful insights into the role of CAD tools in development. 


Can you explain the system that was used to 
do the new products — Viking, Opus, Bulldog, 
Guss — the whole beginning to end of the design? 


Design process? You want to see the design proc- 
ess? Let's go into the War Room. 


(We proceed to the War Room. Inside is a graphic 
display of all the processes involved in product 
development. The flowchart covers all the walls in 
the room.) 


What do you use this room for, who do you bring 
in here? 


The goal was to understand exactly what we're 
doing and how we're doing it — examine every 
step in the design process. 


This really gets the point across, doesn't it? 


Yes, the point is, it's kind of complex. There's an 
awful lot of research, market analysis, structural 
and architectural work that one never sees. But 
when we land it in this room, we know how long 
it takes to make our products and how much time 
is spent in each area. It starts with logic design, 
the capture of circuit information in graphic sym- 
bols. Then on to a simulation process that elec- 
tronically tests whether or not the design makes 
sense. Hopefully you've done a good job with that, 
because now the board goes through a very com- 
plex PC design process into manufacturing, and 
they start to make it real. Out pops the board and 
the engineer starts to test it. Now if he’s made 
mistakes ... We work through the loop again. 


But you have some idea of where the mistake was 
made? 


It happens most often where we have interfaces. 
A computer may have a CPU on one board and 
an I/O system on another, with two different en- 
gineers working on those two boards. And in the 
interface between them, they may have proceeded 
on assumptions that were wrong. What you'd like 
is to simulate to that level — not just the chip or 
the board, but the complete system. ... See those 
purple symbols on the chart? That's another kind 
of interfacing — where somebody has to get in 
there and do something by hand. The secret of 
success is to eliminate that. You put in the job, 
press the button, and out it comes, as quickly as 
it takes you to run around to the other side of the 
machine. 


What are you doing about the interfacing? 


The new products have taught us a lot, we can 
already see that in the next generation that's being 
designed today. I think the design group learned 
their lessons on the simulation side, and we learned 
ours on the pc board system. We learned some 
lessons about database, and some very interesting 
lessons about manufacturing. During that time Man- 
ufacturing was bringing up Cornfield — a whole 
new process. We had to learn how to send the data 
across to them in a way that would make the best 
use of their capability — but nobody really knew 
what that was. It drove us crazy, like coming to 
the office every day and finding a different word 
processor on the system. That's started to settle 
now. | think we know how to go from engineering 
to manufacturing in an automated way. 
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How did this system, the process in this room 
evolve? 


About three years ago we put together a strategy, 
part of which is reflected in this room. And that 
strategy says: the fundamental goal of internal CAD 
tools is to put in place the databases and the glue 
required to make this process flow. Because it’s the 
flow, not the tools, that’s important. The breakup in 
flow is what can jeopardize programs of the size 
we have today. So we put together a series of 
projects designed to address each particular area: 
like simulation, like pc board, like logic capture and 
gate array design, mechanical engineering and bill 
of materials. Then we considered methodologies for 
pulling these areas together and managing a dis- 
tributed environment. 


For example, one of the major requirements for the 
company was to establish a so-called majority sim- 
ulator, so we began work with manufacturing on 
that. Then we revisited our pc board system. We 
put in place a mechanical design tool that interfaces 
to the pc board system in the manufacturing post- 
processing area, so we can get mechanical data 
off of the boards and into the data sets required 
by Manufacturing. We also went out and located 
the next-generation logic capture system, called 
Cericor. That was a nice piece of work, where a 
strategy was put together to identify the most im- 
portant characteristics of this type of product. A 
system was found, we tested it, it was qualified ... 
and through an acquisitions strategy that we worked 
out with the Technical Systems [marketing] group, 
we now own that application. Cericor will be main- 
tained in-house and packaged with our TEO prod- 
uct; so we will become a vendor and a user of this 
tool. 





Are these tools that you're talking about going to 
be able to handle future design challenges? 


Well, in the pc board area we modified the existing 
tools and pushed them just about as far as they 
can be pushed today, by the demands from the 
designers of the boards. I believe we can add new 
tools that are better suited to our densities, the 
demands that we make. But you know, I don't 
believe ... Some may consider this hubris, but | 
think that what counts isn't so much that we have 
the best single tool within any given area. It's being 
able to take the information that's developed by 
each tool and use it, knowing that the information 
is right as we go from one system to the next. Being 
able to pipeline all that data down the engineering 
cycle and over to manufacturing — that counts to 
me. That's going to mean a lot more to this company 
than having the whizziest pc board system in the 
world. 


How much discussion has occurred between your 
group and the design group on these issues? 


We're still a tight enough community that all the 
groups can participate. Engineering can sit down 
with us and say, ‘Well folks, here's what we now 
think of the tools, here’s where we did or didn't use 
them well, and here's what we'd like you to do in 
six months.’ We have a very effective mechanism 
by which organizations can share information, re- 
view programs and give ideas. People meet in the 
War Room biweekly to review every program that's 
going on: it's a well-documented process with a lot 
of follow-up, so they feel that if they come here 
and make a point, it's taken. 


As developers of internal applications, we want to 
channel this feedback into strategic solutions rather 
than reacting to local problems. I want to be able 
to sit the CAD tools group in this room and say, 
‘It takes this long to go from step A to step B. Show 


me how to get there faster. And don't come back 
to me and say you want to develop a new capture 
system or a simulator — | can buy those outside 
and so can you. Show me how to put them together 
in a way that works.’ 


Our job is to make the engineering organizations 
successful, so that's what I want: solutions to the 
problem of getting products done fast. Maybe that 
means we've got to train them in some areas, or 
maybe they've got to train us. But it's communi- 
cation, it's understanding, it's knowing what the 
fundamentals are, and really being inventive about 
using the tools that are there — that's what works. 
I'm always suspicious of people who keep proposing 
new tools to solve the same old problems. Ask them 
to build you a house and you'll end up with a box 
full of hammers and, if you're lucky, a hole in the 
ground to bury the box in. | prefer people who 
propose new products. Then we'll help them to 
design those products. 


CERICOR — THE VENTURE FORTH 


One of the conundrums about tools is that in order to be widely useful, they must be designed with a certain amount of generality; yet in order 
to be fully useful, they must often be tailored to a specific need. This is why, in places like Data General, you often find one set of tools being 
developed for internal use, and another — the company’s product line — being developed for customers. In most organizations these two 
disciplines, by nature complementary, become locked into separate groups that grow increasingly distant, until the exchange of technologies 
between them all but disappears. In the tools area of Engineering Services, however, one project leader showed us it doesn't have to be that 


way. 


In April his project team was reviewing the source files for a tool known internally as Cericor. In a few months they would be working with 
design teams from Guss, TEO, Devios and /VS windows to integrate it into the product line. And a year later engineers would be using this 
tool internally, while Data General was selling it externally as TEO/Electronics in a joint marketing agreement with Fujitsu. In this interview, 





Cericor was just beginning its venture forth. 





"We realized some time ago that our logic capture system had reached 
the end of its architectural development — that the software could not be 
enhanced and maintained properly without radical change to the design. 
We began a proposal for building a new system, and in the process of 
gathering information we found Cericor. 


"While we were interested in the tool for internal use, Marketing saw its 
potential as a product. We purchased a minority interest in Cericor and 
received certain rights to the software: we receive software support, and 
we have the source files so we can enhance the system as we see fit. 


“What it does ... The uniqueness of Cericor is its object-oriented approach 
to development — a departure from the structured programming techniques 
that you find in languages like FORTRAN, PL/1] or C. Essentially this 
approach makes the code more efficient, it's easy to change and modify. 
When it comes to enhancing the program, there's a lot more reuse of code 
and a lot less rewriting it. 


“Another advantage comes from building the program around one cen- 
tralized database which both the logic capture and simulation functions 
can use. In older systems, you would have to run several programs — 
what we call filters — to complete these two functions. The filters would 
massage your data into the appropriate form so you could do simulation 
and get your output. Then the output — usually a printout of complicated 
tables and numbers — had to be scrutinized to figure out what was going 
on. This is the biggest problem for an engineer — trying to get simulated 
results from the logic as rapidly as possible. With Cericor, all you do is 
input your design change in the logic capture system, enter the simulator 
and give it a job, and back come the results almost immediately. You 





never have to exit the program, and it has a nice graphical interface so 
you can quickly see what happened. It's going to save the engineers a 
lot of time, which is the whole point. 


“Our first real user of Cericor was NDG, because we felt they were very 
conservative, very rigorous in their approach to critiquing new systems. 
Now we're customizing the software for the gate array applications they 
do, and we're adding new features for one of our primary vendors so 
they can use it too. What we'd like is to provide interfaces to all the chip 
vendors that our engineers work with, so the system is available to every- 
one. Eventually ... The system is so powerful that I would really love to 
see us develop a whole family of products around this technology. Things 
like an integrated pce board design system, integrated graphics and doc- 
umentation systems — all sorts of software that people haven't been able 
to do before either because they didn't have the working base to construct 
the system, or they hadn't really thought of it. 


“It's an exciting time for us in CAD tools, because software development 
environments and applications are becoming more and more important 
to the company's future. The hardware technologies we're building on will 
make a lot of machines run very fast — and that difference is going to 
show up in software, in the greater power and intelligence of our tools.” 


A YEAR IN DEVELOPMENT 
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Some time after Viking was announced, Tom West is reported to have said that the company owed its 6-MIPS uniprocessor to 
the engineering group, but it owed its 12-MIPS dual-processor to AOS/VS. What he was referring to was the implementation of 
multiprocessor support in the operating system — an idea that had met with some resistance when it was proposed two years 
before. Now, in May, while the Viking engineers were making vendor packs and wiring kludges, the /VS kernel designers had 
successfully run everything but the memory management software on their testbed downstairs. 


It is probably important to remember that operating systems in the genre of AOS/VS were originally built assuming one, and 
only one, CPU. Knowing this makes it easier to appreciate the scope of what was undertaken — to accommodate an environment 
like the dual Viking, where two or more CPUs share the same memory and operating system resources. In the following interview, 


the chief designer of the /VS enhancement tells us how it went on the software side. 


ff ee SSSSSSSSSSSSSSSSSSSSEe 


I understand that it took some time before multi- 
processors gained corporate support. How did it 
start? 


I had written a proposal, a philosophical treatment 
of multiprocessors under AOS/VS, back in October 
of ‘81, but it wasn't until the summer of ‘83 that the 
MV/20000 presented itself as a possible opportunity. 
At the time the corporation wasn't really behind a 
dual processor, and wasn't behind implementing it 
in AOS/VS either. There were other plans in the 
works, other interests ... About the best support I got 
from management was that they left me alone — 
not bad, actually. So I went off with the Viking project 
leader and did a lot of research, resulting in a pro- 
posal for the implementation on both the hardware 
and the software side. Once we got a spec together, 
we set about signing up the software side of the 
house to support it. It took a lot of convincing over 
several months — first, to get minimally staffed; and 





then, to get the people on the team believing that it 
could actually be done. 


What were some of the basic premises you pro- 
ceeded from? 


There were two basic premises that we started out 
with. First, we didn't want this to impact the unipro- 
cessor performance, except to make it better. Second, 
we wanted to treat both processors as symmetric to 
the greatest extent possible, and to minimize any 
interactions between the two processors, because 
interactions generate overhead. 


I'd looked at a number of multiprocessors in the 
master-slave model, particularly the early VAX 
11/782. 'Master-slave' refers to the relationship be- 
tween the processors. In the case of the /782, only 
one processor — the master — could access I/O, 
handle scheduling, execute kernal code and do sys- 
tem calls; all the slave processor could do was com- 
pute. If you wanted to calculate pi to 64 million places 
it was great, but if you wanted to run something 
interactively it was a dog. If each processor provided 
1.0 in performance, dual system performance could 
vary to as high as 1.9 for compute-intensive jobs and 
as low as .89 for interactive ones. With multiproces- 
sors you want to preserve unity as you increment 
CPUs — if one processor delivers 1.0 MIPS, the dual 
version should deliver as close to 2.0 as possible. 


In the beginning we went around to different DG 
production systems and actually counted the system 
calls being used. We took the most frequently-used 
system calls and attempted to get them to run on 
both CPUs to increase the overall system perform- 
ance. In actual implementation, the second processor 
can execute about 50 percent of the calls by count 
and about 80 percent by frequency. We also allow 
both processors to schedule themselves. 


Because our current multiprocessor scheme isn't per- 
fectly symmetric, we prefer to describe it as a ‘mother- 
child’ relationship rather than a ‘master-slave.’ Today 
the mother processor can do some things the child 
can't, like access the file system and I/O. But over 
future revisions of /VS the child can grow up to do 
those things because our basic design doesn't pre- 
clude it and we know how to implement it technically. 
It was really a matter of deciding what functionality 
we could deliver with the MV/20 given-the time and 
resources available to us. 





A YEAR IN DEVELOPMENT 


How did you deal with the problem of implementing 
multiprocessor software for a machine that itself was 
just starting development? 


The solution to that one came from Charlie [CPD 
design engineer], who was building a dual-processor 
testbed for another high-end project. When he found 
out about our needs he completed it and donated it 
to us. A great example of inter-project cooperation, 
and a real godsend. 





The testbed consisted of two MV/4000s tied together 
with a kludge board for certain functions and a bunch 
of memory. So we were actually able to design, 
debug and test in a real multiprocessor environment 
prior to the MV/20000 hardware being available. 
From start to finish I would estimate we ran 
AOS/VS on that testbed for about a year and a half. 


What were the challenges in implementing multi- 
processor capabilities in /VS? 


One of the first things we had to do was go through 
every system call in AOS/VS, analyze all the code 
paths, and figure out where the locking had to be 
done. In a tightly-coupled environment where both 
processors share the same memory and operating 
system, locking is a way of sequencing their actions. 
If processor A looks at a database, finds a value of 
1 and changes it to 0, I want to make sure that 
processor B doesn't also find a value of | and try 
to change it. Otherwise I could wind up with two 
processors doing something they shouldn't, or I could 
have a corrupt database. The solution is to plant a 
lock — a semiphor or flag — that tells one processor 
to wait until the other finishes. 


FROM ONE TO MANY 
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At the same time we wanted to minimize any impact 
on performance. One of the biggest potential prob- 
lems in adding CPUs is the incidence of collisions, 
where two or more processors have to schedule or 
get to a database and one has to wait on the other. 
If you can minimize those waits, you should be able 
to keep a steady increase of processing power as 
you add CPUs. So we put collision counters into our 
locking routines. A collision counter lets me go through 
the whole scheduler area and find out how many 
times I've hit a lock that's in use — a collision. I can 
then run any job and, knowing the paths the job will 
take, I can go in and look at those particular counters. 
If I see a high hit rate on the locks, | may want to 
redesign the area of code that touches them to min- 
imize collisions. So far we've seen very few collisions 
in testing with two processors, which is a good sign; 
next Id like to get onto a four- or six-CPU testbed 
and see if we need to optimize further. 


Scheduling and memory management were the other 
main issues as far as implementation goes. One 
interesting feature to come out of our work on the 
scheduler was automatic load  balan- 


cing — the ability to distribute jobs between the 
processors dynamically, with no user intervention at 
all. Another was the concept of classes, which lets 
the user assign a different workload to each processor 
— maybe dedicate one CPU to all his CAD/CAM 
jobs or use it as a back-end batch server. It's not 


unlike the auto/manual option on a camera in that 
the user can either be involved in or unaware of the 
multiprocessor environment, as he chooses. 


I should also mention that we were a very small 
group of five people, which was a challenge in itself. 
To get everything done we had to approach the work 
giving ourselves as much latitude as possible. For 
instance, after we'd implemented the scheduler, we 
put it in rev 6 of /VS — disabled, of course, as far 
as the field was concerned — and debugged it there. 
That gave us something to play with and figure out 
what changes we should make. When it came to rev 
7, the work we had to do was relatively minor. We 
also needed to analyze and tune the system calls, 
of which there are hundreds in /VS. In this case we 
built a table that says ‘Can this system call run 
anywhere?’ So once we'd debugged the basic struc- 
ture, we could turn the calls on one at a time; if we 
found a problem that couldn't be resolved quickly, 
we'd turn off that system call and keep making for- 
ward progress. We did a similar thing in the memory 
management area — while one designer was work- 
ing on the memory contention piece, we had the 
basic underpinnings in place so we were getting a 


lot done. We could even run Contest, our confidence- 
testing program, as long as we didn't get into memory 
contention. 


By the time the MV/20 was ready for us to run, we'd 
spent months and months in the lab beating away 
on our testbed, tuning and debugging. To illustrate 
how successful it was, the first time the engineers 
got the dual MV/20 up, they loaded our software 





and it ran clean. Since I wasn't there to see it, I kept 
asking them ‘You mean there were no problems? Are 
you sure?’ We still have that testbed in the /VS lab 
— and it's still running! 


You mentioned achieving nearly equal performance 
from two processors. What performance would you 
expect to see with more than two? 


I would expect it to be more hardware- than software- 
dependent. Memory bus access time is a factor — 
if I can't get any more through the memory bus I'm 
going to start seeing a drop-off. Or if I run into I/O 
bottlenecks because I can't distribute a database any 
further, and everyone starts contending for the same 
spindle. Remember, disk access times haven't nec- 
essarily increased at the same rates as the processor 
performance. This is the reason for expanding the 
testbed — so we can start testing these conditions 
with more CPUs and get an early handle on the 
issues. 


In the meantime I think we can go a lot further before 
we hit these types of problems. As I mentioned, our 
collision count on two processors has been low, and 
we're getting very close to unity for each processor 
in our performance analysis. Compute-bound jobs 
see the closest uni/dual ratio, as you might expect. 
Typically it's 2.0, but on some jobs we actually exceed 
that because the jobs on the two CPUs synchronize 
themselves, so system overhead can actually be less 
than in a uniprocessor environment. We've also run 
a CEO mix with an equivalent load of 240 users, 
where we average about 1.82, and a mix of 111 users 
doing INFOS transactions, which has been coming 
out at 1.613. So the software shouldn't be a big issue, 
particularly for something like a quad arrangement 
— we designed the operating system to support n 
processors. And there are a number of things we 
can do in future enhancements to improve perform- 
ance even further — defining a larger subset of 
system calls that both processors can run, letting 
them both handle I/O, creating more and more par- 
allelism between the processors and within the proc- 
esses themselves. There are a few limitations to the 
MV/ architecture for doing this, but I don't see an- 
ything insurmountable. 


A YEAR IN DEVELOPMENT 


Multiprocessors are still a new platform for mini- 
computer applications. Do you think customers will 
be reluctant to try it? 


They shouldn't be. Other than adding a few new CLI 
commands, we're totally compatible with everything 
that came before. We were careful to preserve the 
feeling of a uniprocessor environment, so a user who 
doesn't care what runs on each CPU will find it 
extremely user-friendly. To add a second processor 
all he has to do is bring up the system and issue a 
single CLI command — the load will be balanced 
for him automatically. And if one CPU fails, he can 
reboot using the remaining CPU — either processor 
can be defined as the mother, so he can change that 
at boot time and the software won't care. The same 
would be true with four processors or more. 





Actually, I think there's a perceptual problem with 
multiprocessors, in that the early minicomputer models 
were by and large a failure; the mainframe models 
weren't interactive, you had to tell the operating 
system how to process each job in the batch stream; 
and the more contemporary, multiple micro solutions 
often require software partitioning that isn't practical 
for existing or general-purpose applications. The /VS 
implementation is different from all of them — for 
one thing it's very robust, we've been testing it for 
two years! And without diminishing the inventiveness 
of the people who worked on it, our approach is a 
comparatively straightforward one. For the perform- 
ance needs of a lot of applications that are in the 
mainstream today, I think it's the most correct. 











THE BEAUTY IS 
IN THE SIMPLICITY 


Early operating systems didn't interact with people — they took a job, processed it, and returned the result. Then operating 
systems like AOS/VS emerged with interactive features of great power and scope — complex tools that were deeply satisfying 
to the people who built and used them: the computer-initated. Years later these tools would appear mysterious and arcane to 
new legions of users whose expectations of computing — particularly ‘ease of use’ and ‘friendly interfaces’ — were formed by 
word processors and PCs. 





In May, these expectations were the subject of ongoing discussion (not to mention heated debate) among developers, engineers, 
writers and marketeers. Out of their meetings came a remarkably transformed AOS/VS, with a two-step startup procedure and 
a new System Management Interface [SMI] that presents its services to the user in a friendly, accessible way. The manager of 
the /VS kernel group gave us an overview of this project and steered us to some of the others who made it come together. But 
perhaps the most eloquent explanation came from the designer who said, "My biggest contribution to user-friendly AOS/VS was 
my mother, an intelligent person who doesn't know computers. When she gets into a car with automatic transmission, she turns 
the ignition key and the car starts. She isn't concerned with selecting an intermediate hydraulic pressure for second gear; she 
just wants to go forward. If somebody at her office says, ‘You have a computer for four of you to use as an office machine,’ the 








computer should be easy to use, too.” 





How is the friendly interface for AOS/VS different? 


We used to have what we called the '117 self-evident 
steps’: an elaborate process of installing AOS/VS 
that was handled by a systems programmer or en- 
gineer — someone with considerable technical ex- 
pertise. When AOS/VS moved into the office, that 
process had to become transparent. Today we've 
reduced the complexity to such an extent that a user 
can come up to a log-on banner without having to 
do anything except turn on the power. 


To accomplish this required the efforts of Diagnostics, 
Hardware Engineering and two operating systems 
groups, along with Documentation and Marketing. 
They all had to agree on the way the process would 
flow. Then Manufacturing had to agree to pre-install 
software on the disk: the operating system, FIXUP, 
PCOPY, INSTALLER ... everything needed for pow- 
erup. And that meant diagnostic programs, too. 


We held a regular forum to consider the larger user- 
friendly issues and to resolve interdependencies be- 
tween us. We decided the menus had to look like 
CEO. The Help and Cancel/Exit keys had to be 
available at any level. Each item, sentence, and 
screen was reviewed and agreed on by this group. 





Once we had a design, the documentation people 
translated the sequence of events into menu format. 
Hardware engineering went off and designed the 
diagnostics and PROM code that run after the user 
powers on. Meanwhile, the operating systems groups 
had plenty to worry about — implementing the Starter 
program and the SMI. 


What does Starter do? 


Starter is important to the whole product. It's a stand- 
alone command program that performs normal disk 
operations in a friendly way. For instance, to build 
a system disk you have to do things in a certain 
order — format it, reserve an area for the diagnostic 
operating system, install Sysboot, move in system 
files, prepare the disk and then boot AOS/VS. 





As I mentioned, each step was visible to the user 
and required a considerable amount of work on his 
part. With Starter, we designed a base-line set of 
menus that lead inexperienced users painlessly 
through this process; then, after they've done it a 
few times, they can invoke a keyword facility to go 
from any menu right to a command or another menu. 
One prerequisite for this seamless approach was a 
memory-resident operating system pre-installed on 
the disk — we have the Devios [AOS/DVS] group 
to thank for that. They made Starter work better in 
other ways, too — by letting Manufacturing copy a 
disk in two or three minutes instead of half an hour; 
and by showing the documentation people how to 
compact the menu screens so they take up less mem- 


ory. 


Where does the SMI come in? 


With Starter you have this very friendly interface 
from the time you power up to the time you log on. 
Imagine entering your password and suddenly being 
left on your own in the CLI [Command Line Inter- 
preter]. Marketing felt it was just the pits. After mak- 
ing it easier for system managers to build a disk or 
install new system software, it didn't seem fair to 
leave them hanging in the operating system. So we 
have SMI — a user-friendly interface to assist them. 


A YEAR IN DEVELOPMENT 


Many of us who worked on the SMI had worked on 
user-friendly issues for the DESKTOP GENERATION. 
But for this product we wanted a command program, 
not just a few macros tacked on at the front end. To 
start, we listed operations the system manager and 
user would do from the SMI. There were endless 
meetings to determine what to include. The interface 
had to do those CLI operations that you hate and 
need an easier way to do. 


The scenario we finally agreed on lets the end user 
do anything a system manager can do from the first 
three choices on the main menu. Only those with 
system manager privileges in their profiles see choices 
4 and 5. The system management part is a submenu 
to the main menu called Administrative Functions, 
and choice 5 starts the system management tutorial. 





How has the friendly interface been received? 


You had to see it to appreciate the response. When 
we showed it people said, "Wow, it works!" To see 
the machine power on and go to logon ... To see 
Dave Lyons [Vice President of Group Marketing] sit 
down and create a user profile without having to 
use a difficult utility, then log off and log on again 
as himself — and appear comfortable doing it — 
made me feel great. He said customers would be 
thrilled. We had a customer, the U.S. Forest Service, 
come look at it. They loved it, absolutely loved it. 
They made suggestions which we'd like to do. We 
have many requests for SMI extensions. 


So you see this as a continuing effort? 


Absolutely. We have a product that works. We've 
defined a base and established ground rules for user- 
friendliness. The SMI may have weaknesses, but it's 
out there running and anything in the future has to 
look like it. 
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THE HIGHROAD 


TO SYSTEM 
MANAGEMENT 


"We based the initial cut of the System Management Interface [SMI] 
on our experience with the DESKTOP GENERATION and input from 
customers. They had built interfaces of their own using CLI macros, 
which gave us a feeling for the functions a customer would most ap- 
preciate. So in essence we were starting from square two instead of 
square one, the difference being that we would present a coherent world 
view to the user through a formal program with built-in intelligence. 


“It started as a one-page list of system management tasks that needed 
to be made easier — we didn't expect it to grow much beyond that. 
First Documentation and Marketing added to it; then, the more we met 
about the screens and the more people we talked to, the more things 
we uncovered that needed to be built in. Our list grew at a tremendous 
rate — there are over 100 screens in the end product, not including the 
Starter program or the rest of the interface. 


"One of the guiding principles we followed in software development 
was that we wouldn't tolerate something that would be annoying to us. 
And there's nothing more annoying to an experienced user than going 
through eight menus to do something, as sometimes happens in CEO. 
Even a new user will grow impatient with menus once he gets up to 
speed. This was the origin of the keyword facility, which we carried 
through from Starter into the SMI. 


"On the documentation side, we made sure the screens were consistent 
with products we already had, that the language was concise and the 
technical information correct. We spent the longest time on the first 
menus, passing them out for review, refining them based on the input, 
tweaking, expanding or changing things completely — we weren't fussy 
about whose good ideas we used. | think that exercise has given us a 
reasonably sound end product.” 





“The working prototype was real culture shock to practically everyone 
who's used /VS. People who really know the system found it difficult 
at first, while the more casual /VS users loved it — they just power it 
on and it comes up. But even the experts appreciate things like creating 
profiles in the SMI. It's just a lot more convenient than answering weird 
questions from the PREDITOR utility like ‘change priority,’ which no one 
really knows the meaning of. 


“One of the most rewarding things about designing an interactive product 
was the interaction between people to make it come together. To have 
hardware and software engineers, Marketing and Documentation sit 
down and say, ‘Okay, we all want this thing to look good. Now who 
needs to do what to make it work?’ That really was the most satisfying 
part of the project.” 


LEARNING 
ON-LINE 


“The interactive tutorial provided an answer for a human factors problem: 
users are increasingly reluctant to open books. When you read the paper 
over breakfast, you encounter one of the dilemmas of cognitive process- 
ing — you either want to concentrate on breakfast or the paper. The 
same thing happens when you try to learn about something on a 
computer screen by reading a book — you want to read the book or 
use the software, but not both. 





"The on-line tutorial was to help nontechnical people manage their 
systems, so I turned to our system managers in-house for my research. 
There were also the issues of making the screen presentation consistent 
with the rest of the interface, and of where the tutorial would fit in the 
rest of the SMI program. This issue of fit became very important to me 
in trying to construct not just an interactive, but an active, learning 
process. I used the DG authoring system to create CAI [computer-aided 
instruction] screens that can branch to a running program — so the 
user can move from the tutorial into the SMI and get some meaningful 
practice, while still in the tutorial mode. What that means is that users 
can exercise all the SMI functions — create and delete profiles, fill in 
screens or move through menus — without worrying about inflicting 
damage on their systems. The tutorial becomes a filter that lets them 
interact with a mirror image of the SMI, a much more life-like exercise 
than any imitative routines that I might contrive. 


“Writing a tutorial differs from writing manuals. You have to be a 
designer and teacher as well as a writer. The sequence and manner 
in which you present information is all-important. People expect CAI to 
work, and they object strongly if you confuse or mislead them. A tutorial 
needs much more interactivity to keep people interested. The interaction 
and branching have to be thoroughly debugged, and the writing has 
to be lean to save space — in these respects developing CAI resembles 
programming.” 


A YEAR IN DEVELOPMENT 














TESTING, 
TESTING ... 


"In the diagnostics area we had four engineering goals: one was to 
reduce costs; another was to test as much hardware during the powerup 
sequence as possible; a third was to provide flexibility; and a fourth 
was to integrate user-friendliness. We achieved all four. 


“There's been a major evolution in diagnostics, which have traditionally 
been burned once and for all into PROMs before the product ships. To 
reduce costs, we took most PROMs out of the board and made everything 
writeable. That gave us flexibility — we could change our code daily 
and distribute updates on floppies. We use just two small PROMs to 
get everything started — they do some initial testing, then look for ADEX, 
the diagnostic executive, on a floppy, tape, or Winchester disk. We sneak 
through its file structure, find the files we need and bring them in, all 
without having to run the operating system. 





“We can do a lot more testing now because we're no longer constrained 
by the space limitations that PROMs impose — in fact, the MV/2000DC 
is the first machine to fully test optional devices. Initially we make sure 
that everything accessible by the I/O processor — devices like the floppy 
disk, for instance, which brings in the remaining diagnostics — functions 
properly. After the CPU is tested, a sizer program searches for optional 
boards and provides a shell for the diagnostics in PROM on each option 
board. For example, diagnostics test the DS/7500 video board's memory 
functions, the 8031 microprocessor that controls the graphics display, 
and all the major gate arrays. We went by the rule: whatever can be 
tested will be tested. By the time you've powered up and the system 
code is loaded, you know your system hardware is functional. 


"Since Viking, Kite and several other systems were being developed at 
the same time as the MV/2000, this project presented an opportunity to 
create a uniform powerup sequence for different classes of machines. 
Originally it was proposed to load and run diagnostics through 
AOS/VS. We argued that some customers won't own /VS, which requires 
a certain kind of terminal; they may use paper terminals or buy them 
from another vendor. We wanted to make sure that the diagnostic menus 
could run on any customer site, tolerate paper, and still look consistent 
with the /VS model. That turned out to be a good move. An MV/2 
customer may choose a video display and an MV/20 customer may 
prefer paper, but the menu scheme looks the same on both. 


"This project has been a great example of saving time by creating a 
well-thought-out spec up front. At first that may sound counter-intuitive: 
you think, ‘The planning gets 10 percent of my time and the work 90 
percent.’ But the attention given to planning reduced our work by 20 
percent. For instance, the only way to make the startup consistent among 
machines with different operating systems was to pull a cold and warm 
boot trick with ADEX — a sleight of hand that had to be coordinated 
with Corporate Diagnostics. The spec was so clear that everyone could 
totally understand the task. We could go off for weeks and months at 
a time with no questions asked, just taking care of the hundreds of 
things required to produce that one big step the customer sees.” 





FIDOS — MORE 
VALUE ADDED 


“Our contribution to user-friendly /VS was actually a small thing — it 
wasn't planned but came as a sort of corollary benefit from our work 
on the MV/2000DC firmware. FIDOS is really a program for the 80186 
chip, which integrates all the device controllers in the workstation. It 
uses a DG device protocol called Unicorn to act as an interface between 
the operating system and devices, so they can talk to each other in a 
generic way. As it turns out, the Unicorn interface also made it feasible 
to pre-install AOS/VS on disk — a prerequisite for user-friendly startup. 


“Without the Unicorn interface, Manufacturing would have had to run 
a disk initializer program on every disk before they could pre-install the 
software. In the past, most people have used some kind of initializer to 
locate, record and keep track of bad blocks on disks so the operating 
system won't write to the blocks at runtime. Unfortunately, it takes an 
hour or more per disk to run the initializer. We tested an alternate 
strategy, using the Unicorn interface in FIDOS to make disks identical 
logically. FIDOS now locates and tracks bad blocks. Every time the 
system powers on, FIDOS goes out to the disk, reads a defect table, 
and uses the information to map around defects. The operating system 
doesn't have to deal with bad blocks anymore because FIDOS does it. 


“Now when we have a working system, we give it to Manufacturing 
and they can copy it in minutes. For us it was just a matter of making 
some minor accommodations in the firmware. But for them it meant pre- 
installed software.” 








A WHOLE SYSTEMS APPROACH 


Like many of the year’s development initiatives, this one depended on 
the ability of disparate groups to work in an interdisciplinary context. 
As one participant concluded, 


“When a customer buys a system he expects just that — a coherent 
whole. That can be difficult when you're building from an existing 
architecture: it can't be changed overnight, you have to make compro- 
mises. | think we did a pretty good job for one of our first efforts — 
many users wouldn't recognize the Starter and SMI programs as a series 
of compromises. It gets back to the systems approach — focusing a 
multidisciplined team on the whole product and putting the user at the 
forefront. We had a wonderful group of people committed to making it 
work. You never got an answer that they couldn't do it. People would 
usually say ‘I can do it’ or ‘It's a problem, but I'll get back to you.’ And 
they usually came back with a solution.” 
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“I have just one word of advice for you boy, plastics.” 


from The Graduate 





MECHANICAL 
ADVANTAGE 








In physics the term mechanical advantage refers to the ratio of output to input forces. It is a notion of leverage, 
whereby a simple tool such as a lever or pulley significantly amplifies human strength. It could be said of the Bulldog 
package design that it, too, used simple but clever devices to produce a powerful result. 


This month, while the insides of the workstation lay strewn across benches in the engineering lab, the housing was 
coming together on the electronic drawing boards downstairs and would soon be in move-in condition. In the following 
interview, we asked the principal industrial designer and mechanical engineer to discuss the mechanical advantages 


of Bulldog — the MV/2000DC. 


I've heard a lot of good things about the 
MV/2000DC package, and I'd like to know more 
about it. What are the special features? 


Peter (chief industrial designer): Just about the whole 
approach is different. Never before has anyone so 
totally taken the plastic enclosure and used it as the 
structure for the product — at least not in this class 
of machine. Most of the sheet metal is used for 
individual bracketry. The plastic is really pushed to 
do as much as it possibly can in terms of exterior 
and interior support. 


Al (lead mechanical engineer): Our direct compet- 
itors still use a sheet metal or steel structure with 
plastic trim. We did just the opposite: we use plastic, 
with nickel-coated spray and aluminized mylar for 
shielding. 


Why was this product different? 


Al: Basically it was cost goals. We found this a more 
economical way to both manufacture the parts and 
to assemble the end product. 


Peter: The overall structure is an I-beam, which acts 
as a support for the components and allows us to 
leave open the maximum amount of space for access. 
As a result, we wind up with the most efficient number 
of walls. We're not throwing one wall on top of 
another wall just to cover up something and make 
it look better. Ours is a natural economy, where each 
surface is actually used to do something. That makes 
a much cleaner product. 


What about the backpanel — that was done away 
with completely, and connectors that normally go 
there were put somewhere else? 


Al: Right. Again, we were driven by cost. A back- 
panel could cost up to $500. By using stackable 
connectors on the front-end of each pc board, we 
were able to eliminate the backpanel and run the 
I/O directly between each board in the system. The 
external I/O connectors are a simple modification to 
an existing high-density type connector. 


Peter: The stackable connector scheme is much more 
feasible when you limit the number of boards in the 
system. A set of 14 boards’ would be unwieldy to 
service with this type of scheme. In the MV/2000DC 
we have at most three layers ... a stack of three 
boards. 


Al: With a backpanel we would have had to provide 
front access for service, so the FE or customer could 
slide boards in and out. That would have really 
complicated any type of design and the appearance 
of the cabinet. Instead, the MV/2000DC has sym- 
metrical side panels that open like a clam shell. 








Eliminating the backpanel also eliminated extra sheet 
metal needed for card guides. 


We did a lot of work in the plastic, and yet the overall 
package looks very simple. | think that's what we 
strived for — the simpler something looks, the simpler 
it is to build and maintain. 


Peter: What's really nice about it is that you can see 
the benefit. And the reason the product succeeds is 
because design and engineering really worked to- 
gether at the same time. It wasn't isolated devel- 
opment — it was very much development that 
happened together. When you look at the product, 
you don’t see where the mechanical engineering 
stops and the industrial design takes over: they both 
affected each other very closely. 


What were some of the technical problems in im- 
plementing these features? 


Al: The plastic. Everything else was pretty straight- 
forward: the plastic posed most of the difficulty. We 
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had to take into consideration the tooling that would 
be used to make this plastic, and the selection of 
material. This is a unit that's going to sit on the floor, 
that a person can sit on or stand on and use to 
change light bulbs. So a very high-performance en- 
gineering material had to be a consideration. 


Peter: And as the design progressed ... The basic 
I-beam structure remained clear, but it also became 
a cantilevered structure. So even more important was 
what type of plastic this was made of, and what kind 
of testing would be needed to make sure it holds up 
under normal operation. 


Al: I was in Japan twice: first to review the final 
plastic drawings with the tool maker, and the second 
time — for six weeks — to sample the molds, adjust 
them, and incorporate some additional design 
changes. We had 1900 chassis molded in Japan: 500 
went to Singapore and 1400 went to Westbrook, Maine 
where they were painted. 


Peter: An interesting sidelight is the gamble that DG 
had to take in molding so many parts from this tool 
in Japan, and then shipping it to the final molder in 
the U.S. Now there's any number of things that could 
have happened to that tool ... 





Al: It was a double operation: first we had to get 
tooling quotes from both the U.S. and Japan for rea- 
sons of cost and time; we found that Japan offered 
the best price and quickest turnaround. Then we had 
to quote both Japanese and U.S. vendors who could 
mold the part, because we knew sooner or later the 
14-ton tool would be shipped to the U.S. 














I've heard the term ‘injecting it with colored plas- 
tics.’ What does that mean? 


Al: The parts themselves are molded in light camel. 
So that in case the customer scrapes or scratches 
the painted surface, the natural color of the plastic 
below it will hide the scratches. 


Why paint it? 


Peter: The structural foam process doesn't yield a 
good surface finish, but it was the best choice for 
our strength and overall size requirements. The col- 
ored plastic shows swirl marks and other imperfec- 
tions that just aren't appropriate, so we paint it to 
improve the part's appearance. 


I want to ask about the tools you use in 
Mechanical Design — the McAuto CAD/CAM sys- 
tem. Was that important? 


Al: The way the MV/2000DC program went, we had 
five designers working on the CADs simultaneously: 
one designer on the chassis, another on the side 
panels, a third on the rear panel, another designer 
on the pc boards, and the fifth on sheet metal. Every 
day we had people working on the project at the 
same time, then at night we'd take those five indi- 
vidual files and merge them together, checking them 
for interferences — making sure that one person 
wasn't using another person's area. Because every- 
thing's drawn to scale, any interference would be 
obvious. We used different colors for each layer, 
which lets us activate certain parts at different times, 
and we checked all the form-fit functions. The next 
morning each designer would progress with his or 
her layers, then at night we’d merge them again. 
Meanwhile, we had another person designing the 
cables: she was actually able to take our CAD file 
and design her cables right around our sheet metal 
and plastic. So the CAD allowed us to have multiple 
designers on one project with the necessary confi- 
dence. 





Peter: If you were to do it on paper, you'd have to 
continue to duplicate drawings, layering one drawing 
over another on top of a drawing board and really 
working through all the numbers to see if they mesh 
or not. The CAD took all that away. 


Al: I know if we didn't utilize a CAD system we 
wouldn't have met our design goals — not in the 
time frame that marketing wanted to announce the 
system. It took us only six weeks to design the entire 
product. 





It sounds like absolutely nothing went wrong during 
this project ... 


Peter: Nothing at all. (laughs) Of course there were 
plenty of problems along the way, as there are in 
any high-pressure program. We cursed at the CAD 
at times, we cursed at each other ... but overall | 


consider the program a huge success. We were shoot- 
ing for very tough goals on this product, and we 
surpassed them. 





From a customer's perspective, what does the 
MV/2000DC buy him? 


Peter: A low-cost product that he can place very 
easily in his office; at 50 to 70 pounds, it's not all 
that tough to move. The side panels remove easily 
in order to upgrade or service any of the components. 
Captive fasteners throughout the product minimize 
the amount of loose hardware that could get lost 
under a rug. You have index-type cards in the back 
of the unit to help cable up the system, so you always 
know what cable goes to what connector and whose 
system it connects to. You have helper graphics on 
the inside of the system that reinforce how to take 
out individual pc boards, and then all the standard 
warning statements inside. 


Al: I believe the MV/2000DC is easier for the cus- 
tomer to own and service than anything we've ever 
designed. We're down to the basic flathead and 
Phillips-head screwdrivers for complete assembly and 
disassembly of the system. 
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What about from a manufacturing perspec- 
tive — what gains have we made? 


Peter: In the assembly method ... how you put all 
this together ... as the unit goes down the line it's 
easier to add the individual components once you've 
got all the hardware and the basic cabling in place. 


Al: The way Apex is assembling them, the 
MV/2000DC is mounted on a pallette that rolls down 
their conveyor system. There's only one main cable 
to install, and they just start building onto the chassis. 
The chassis is already molded in plastic, so they 
don't have to assemble it. 





Peter: It's very much an additive and layering proc- 
ess all the way down the assembly line. It's not as 
if you have to create a partial structure, add a com- 
ponent, and then try to weave through cabling and 
wires and various fasteners and screws. The whole 
process of assembly works very well. At the very 
end we really did a nice job when you put this 
product in its cardboard packing. The packing is so 
constructed that when you take a box and lay it on 
the floor, you can tip it up and get the product out 
very easily — without having to remove a whole 
bunch of foam pieces and really being sloppy about 
it. It's just very comfortable, so easy to use you don't 
even notice it. And that's really the statement about 
this product: it's so obviously right that you really 
don't have to question it. It just works. 


Is there anything else you'd like to add that I haven't 
asked about? 


Peter: We're entering the product in several com- 
petitions — two different types of design competition 
and one for structural foam. The results aren't all in 
yet, but in the structural foam competition we came 
out number two in our category. 


Al: The number one winner was a microfiche read- 
er — an important application in its own right, but 
not in direct competition with the MV/2000DC 
product. In our application — the under-the-desk 
CPU — there are a number of decent competitors 
out there, and the MV/2000DC was judged second 
to none of them. I think that says it all. 
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Truth is beauty, beauty expensive. 
A thing of beauty is a job forever 
and a manual of beauty a joy 
until the next rev ... 


MANUAL LABORS 


To support the most extensive product introduction in Data General's history, the Customer Documentation group turned 
to a new tool, the workstation-based publishing system. Their shipment arrived from Interleaf one June day, drawing 
scores of interested or simply curious onlookers as the system was unveiled. The honeymoon, in which user and 
computer get acquainted, was brief: the first books were due in November. Here some of the group talks about how 
it made the transition — from system evaluation and purchase to bound manuals — in less than a year. 








“Even though our publishing process has been automated for some 
time, manuals were typically produced in several stages and by 
several hands. From writer to editor, then on to typesetting and 
illustration: that was the first production pass. Then back to the 
writing group for review, and back to the production group for 
corrections.” 


“That system was adequate for normal loads, and minor enhance- 
ments kept it going for several years. But then, ‘normal’ is always 
subject to redefinition. Every year the product line and the docu- 
mentation requirements would expand. Until finally we saw all 
these new products coming through the pipeline — an estimated 
2700 pages of technical documentation. That figure exceeded our 
in-house capacity by 100 percent.” 





“It was the completeness of the package, | think, that made sense: 
having the typesetting, the graphics — really the whole publishing 
process integrated in one place.” 


“The software allows you to set up page formats, and the graphics 
program lets you create illustrations and place them on the finished 
page. Any changes are made interactively because the screen 
representation is WYSIWYG — what you see is what you get. 
Although Interleaf runs on top of Unix, they told us it could accept 
our /VS files through a conversion program that would supply a 
formatted result. They also showed us a scanner that could accept 
our existing artwork, as well as halftone photos ... and a laser 
printer that produces a camera-ready finished page.” 





“We'd looked at a number of alternative systems — Penta, Texet, 
and XYvision. So when four of us set off for Cambridge one morning 
to investigate Interleaf, we had a pretty good basis for comparison. 
We didn't really expect to be impressed. But when I came out of 
the demo, I felt like I'd been given a hard sell. It wasn't the sales 
rep — it was the product. The equipment sold itself.” 
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“We had to make a business case for Interleaf in order to get the 
purchase approved. That in itself was interesting and turned out 
to be very important later on, because it gave Interleaf some 
visibility in development. A lot of hardware and software engineers 
got interested because they were developing the same things we 
were using — windows, desktop icons, and graphics workstations.” 


“After the system arrived came the real challenges — getting it 
up and running, tying it into our system, and learning how to use 
it. We knew the TCP/IP package that DG was coming up with 
would allow file transfers and virtual terminal activity between our 
equipment and brand X computer. But in the meantime we had 
to tie the DG machine to Interleaf with an async line. This involved 
a certain learning curve because it had never been tried. Looking 
back, it seems like quite a gamble: real manuals were slated for 
production in just a few short months.” 





"To me the biggest concern was figuring out how to have Interleaf 
accepted by the group. We were asking them to do things they 
hadn't done before ... to work on terminals they'd never used, and 
to think more visually than they had in the past. Naturally, some 
were reluctuant to learn a new method. The early converts were 
the ones who discovered they could have greater control over the 
whole design of their documentation.” 
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"The first manuals to put Interleaf to the test were the new product 
introductions. For us it was a struggle, learning how to use Interleaf 
at the same time that we were trying to produce finished manuals 
for the November announcement. Not just learning a new tool, but 
learning new relationships between writer and editor. Some time 
was wasted, some efforts duplicated in working out the procedure. 
There's no book you can read that says this is how you're supposed 
to do it ... We were writing the book.” 





“Don't ask me how, but we did it: the manuals were delivered on 
time. As usual the product specs were changing right up to the 
last minute, but Interleaf allowed us to incorporate those changes 
instantaneously. And now ... We've never had so many compli- 
ments — about how well the manuals are written and how clean 
and professional they look. All the start-up problems were worth 
it to produce this kind of result.” 


“When Bill [then CPD Director] came to Data General he did two 
important things: one was pushing for the intelligent workstation 
in development; the other was advocating its use as a tool. Now 
it's starting to take hold: after the success of the first manuals, 
others are using the system and appreciating what it can do. From 
hereon the process will just get better and better.” 
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UNCOMMON COMPONENTS 





In software, large programs have traditionally been developed as a series of components, each designed by a small team. While 
this method makes the program more manageable, it introduces costly duplications when there are several programs — languages 
or operating systems, for instance — with components more or less alike. 


To deal with that issue, Data General's software development organization had started the practice of building common components 
— common, as in shared by many, but also uncommon in the efficiency they bring to the design process. In June that efficiency 
was paying off all over the place — enabling small teams to support an unprecedented number of products along with new 
technology initiatives of their own. Here a section manager of Languages Development talks about the use of common components 


as it applies to his group. 





What does common component development mean, 
and what is its purpose? 


We were in the business of building compilers — 
FORTRAN compilers, COBOL compilers — and we 
treated them as common components because lan- 
guages are basically the same. A COBOL compiler 
translates a COBOL program into a common inter- 
mediate format; FORTRAN, Pascal and BASIC com- 
pilers do the same thing. So we had all these 
intermediate formats — a common point for all the 
languages. 


The purpose of all this ... it means we have fewer 
pieces. We don't have nine code generators, nine 
optimizers — we have one. Which means that one 
person can maintain the optimizer, and when he 
makes an enhancement it propagates across all lan- 
guages. The leverage on this is incredible: it's more 
maintainable, faster, and costs less to produce. 


Could you explain in more detail what some of these 
pieces are — the code generator, the optimizer ... 


If you consider two languages, COBOL and FOR- 
TRAN, they look very different when you compare 
programs written in both. But deep underneath they're 
really the same. They may do things in different 
ways but ... let me explain what a compiler does. 


You have code written in FORTRAN that looks one 
way, while the same expression looks a different way 
when written in COBOL. That language-specific code 
has to be translated into computer-understandable 
code — the compiler does that. A compiler has a 
few standard pieces — one of them, at the front end, 
is language-specific in that it understands what FOR- 
TRAN statements do and breaks them down into 
language-independent pieces. That process of break- 
ing down the the language code is called parsing. 
The parsed information is stored in a generic format, 
what we call the intermediate language. But it isn't 
machine code yet — it’s just some logical information 
like ‘add 1 to y and put in x.’ A machine can't 
understand that. 


Another piece of the compiler — the code gener- 
ator — is what actually generates machine-readable 
instructions. And the code generated can be the same 
for a lot of languages. So the cost of building a new 
language and a new compiler for it can be as small 
as writing a new parser. 


How involved is that? 


Well, we developed a utility called the parser gen- 
erator. You feed it a description of a language — 
what COBOL is, for example — and it generates a 


parser for you. So the job of building the front 
end — maybe a quarter of the compiler — takes 
only five percent of the time it might take if you were 
to start from scratch. 


As it happens, some of the small languages like C 
and Pascal have fewer elements when they're trans- 
lated into this intermediate language. As a result, 
building the code generator is ... well, like layers of 
an onion. In the middle you have C which is quite 
simple. To write a code generator for Pascal you add 
to the C generator, to do one for FORTRAN you add 
more to that, and so on. More recently we've added 
ADA elements to the code generator — that's a larger 
language than any others we've seen before. 





Can you talk about the Global Optimizer, why it 
was developed, what it’s used for? 


The optimizer comes in after the language has been 
parsed into generic statements, but before it’s trans- 
lated into machine code. It's a tool that optimizes the 
intermediate language by removing extraneous state- 
ments and choosing better instructions, which im- 
prove the quality of your code and make it run faster. 
In the case of ‘add | to 1 and put in x,’ the optimizer 
would know that this is really an increment statement, 
so it would choose an Increment instruction instead 
of an Add. And because it’s the same optimizer for 
all the compilers, we've leveraged it a lot. 


When we develop a new MV/system we always 
announce its MIPS rating — its instruction speed. 
That's measured with the Whetstone benchmark, a 
program written in FORTRAN. You compile the Whet- 
stone program through the optimizer and code gen- 
erator, which creates all the right code, and then you 
tun that code on the new MV/ to see how fast it is. 
Clearly, any work you can do to improve the optim- 
izer speeds up that Whetstone result and makes the 
machine a little faster. For instance, the performance 
increase of the MV/20 since it was announced comes 
in part from our work with the Global Optimizer. And 
that goes right to the bottom line of the company — 
sales. 


The optimizer is the work of one person. Every time 
we build a new machine we put him on it and he 
wrings more MIPS out of it. 
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Are there different considerations when you're de- 
signing a common component as opposed to one 
that's tailored to an individual product? How much 
tailoring do we do now? 


None of the language products we're now building 
are tailored. They're all designed to have a multiple 
use. Yes, there are some things you need to keep in 
mind when you're doing multiple-use components. 
You have to pay more attention to using high-level 
languages so you get more flexibility. And when we 
release a revision of the common code generator we 
have to make sure it passes all the test sets for all 
the languages. That's a big effort. If you find a bug 
in the BASIC tests and fix that by changing some 
common code, you then have to worry about whether 
you've broken something in the FORTRAN tests as 
a result. 


But the good news is that once you get it working 
you know it's reliable because you've exercised it 
very thoroughly. You pay for it up front, but you reap 
the benefits over a long period of time. It's a good 
business decision. 


Will customers be affected by, and use, these ad- 
vantages? 


Yes. Because these languages are common down to 
the machine level it means you can write an appli- 
cation in a mix of languages. You can mix FORTRAN, 
Pascal and COBOL code in one application and it 
works together well. When we bought the ADA com- 
piler it wasn't a common component compiler, it was 
customized for that particular language. And we spent 
quite a bit of time replacing its code generator with 
this one, so the customer can call other language 
routines from ADA. Our ADA customers have a sub- 
stantial investment in FORTRAN programs, and if 
they had to recode them for ADA the time and cost 
would be phenomenal. 


The concept of mixed languages has been useful to 
us as well — in cases where a compiler is written 
in PL/| but has runtimes in C, the ability to mix the 
two helps us a lot. Likewise in operating systems 
development, where you have a large product with 
many people contributing to it, designers have the 
flexibility of working in the language of their choice. 


In fact, our customers realize many of the same 
benefits of common components that we do. If it costs 
us less to build one optimizer for all our compilers, 
it costs the customer less to buy one optimizer that 
works on all his code. We're all doing program de- 
velopment of one kind or another, and languages 
are the common denominator — we can all benefit 
from more efficient program development tools. 
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A ROOM WITH A VIEW 


An organization is an assemblage of dynamic parts, always forming, shifting, and regrouping around a central activity. 
At most companies there is no single person or place that can explain how all the pieces play together; only years of 
observation and experience can do that. At Data General, however, a small group had been examining the company’s 
vital functions in painstaking detail to create a visual picture of the entire development and manufacturing process. Now 
people were using that picture to manage the most ungodly amount of PCB activity they'd ever seen. 


In "CAD CAN" we went inside the War Room, where this picture lives. Now the room's principal architect explains how 


it came together. 





"This room reflects all the computer-aided engineering, computer-aided design, 
computer-aided manufacturing, and computer-aided test processes that support 
product development. You cannot isolate one of these processes without under- 
standing how they work as a whole. And they work right underneath our corporate 
product strategy — which is to develop a product to specifications, work toward 
a manufacturing and quality plan, and come out with a significant return on 
investment based on the cost of that effort. 


“The room is a series of concentric cycles, a set of convolutions that are ongoing. 
It doesn't look as though it has any direction, but it does. There are four distinct 
areas ... 


“It begins with research, planning, and design. Product specs are the key to what 
happens in R & D: selecting technologies and partitioning the functionality of a 
system to meet product objectives. The architecture of a system is defined here, 
and the performance of the design is analyzed through simulation. It's here that 
we do logic capture and send data to our vendors — to Motorola in the case of 
the MV/20000, Fujitsu in the case of the DS/ systems, or Sunnyvale in the case 
of the MV/7800. 


“Then we enter development — the spiralling world of CAE/CAD/CAM/CAT. 
This series of operations works on component selection, design, qualifications, 
and specification in conjuction with Design, Mechanical, Manufacturing, and Test 
Engineering. These operations are working in parallel with Design Assurance 
Engineering, Diagnostics, Manufacturing Planning, Product Documentation, and 
Field Engineering. A total of 16 major processes are interrelated and focused on 
developing a product definition to be used by plant Manufacturing, Marketing, 
and Field Engineering functions. A product has to be defined in terms of all its 
parts — both singularly and in relation to each other. To do this the development 
process focuses on getting the right data to the right place at the right time. 


“Next we take the product as it's been defined and redefine it for Manufacturing. 
Using data from the physical design system and the parts library, we output pc 
board assembly drawings, plots, parts lists, net lists, photo tools, hole counts, x- 
y coordinates, and drill data. Mechanical designs are defined for fabrication and 
assembly. The assembly process programs for automation are built here, then 
factory management and inventory availability processes go to work. In manu- 
facturing, the focus is on having the right part at the right place at the right time. 


“Meanwhile early in the development cycle, the Test Engineering world has 
begun with the analysis of product specifications, and component and board 
design specs in order to develop test programs and test equipment processes. 
The entire design and test interface is targeted to the performance levels antic- 
ipated in the initial prototype build, and assures product quality in subsequent 
sample production build programs and first customer shipment. 


"The beauty of the room is that we can now see the dimensions of things that 
used to be abstract. If a developer is discussing modifications to a process he 
can come in here, use a pen and say ‘We're going to change it here,’ or ‘It'll 
take me three months here.’ Instead of just listening to him talk abstractly, people 
can visualize it and begin to ask questions. By making a change at point A it 
becomes obvious how that will impact point C. We can physically see and touch 
the process. 
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"Throughout this process there are many boards and gate arrays coming down 
the pike and getting defined by Design Engineering for Manufacturing, while 
other products are still back at the beginning. It requires a lot of integration; 
integration requires organization; organization requires management ... so that's 
what this room helps the company to do — manage product development. 


“With a group of people talking about an interface, actually seeing where it takes 
place and the time required — the room becomes a planning device. When their 
focus shifts from one area to another, they can condense the old area onto one 
panel and use the extra panel to expand on the new area of focus. So the room 
is mobile — it becomes a reflecting device in terms of what's happening today. 


"As I've seen this room develop, | was amazed at the complexity of it all, and 
yet the overall simplicity. It's like a symphony, everyone playing on a different 
set of instruments. While one side of the world is working on components and 
their test equipment, the other is developing a manufacturing process for the 
board so that when it's done, the test equipment, manufacturing process, and 
components are in place. This was very difficult to capture because most of the 
process wasn't documented — we had to get people in here and sketch the 
panels in crayon. Then we had to conceptualize it — it's not just knowing the 
facts — it's also how you model and abstract them. 


“Over 60 people participated in putting this together. Many contributed their 
knowledge, others helped with the presentation and graphic design. I suspect no 
one else has anything like it — it would be like saying to another company, ‘Do 
you have 63 people who would work together, voluntarily, on this?’ Probably not. 
We were very lucky to find people who would cooperate and contribute without 
really knowing what it was going to turn into. 


“What it turned into is a map of the product development world. A navigational 
tool — that was the key. We had to see what the world looked like in order to 
chart a course from point A to point Z in the fastest way via reliable data. My 
feeling is that if we're able to isolate the key data linkage points — if it's done 
right and we're able to manage and qualify our data — then the data that drives 
that process will produce quality products, on schedule, at the lowest possible 
cost.” 
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GOING FLAT OUT 


No picture of a company’s vital functions would be complete without a sense of the organizational personalities that drive it 
forward — or that bring it on occasion to a grinding halt. We found this little fable circulating over the CEO network and thought 
it captured the corporate gestalt rather well. The original source, rumored to be Marketing, is unknown. Needless to say, it didn't 
come from the War Room. ... 


A bunch of DG employees are racing down the freeway in a very large bus on their way to a regional sales meeting, when a tire blows out. The employees include a 
sales rep, systems engineer, field engineer, corporate marketing rep, corporate controller, manufacturing rep, Westboro hardware engineer, NDG hardware engineer, 
software development manager, German sales rep, corporate diagnostics programmer, DAE test engineer, PFA representative, corporate PR person, business planner, 





sales administrator, corporate business group member, regional sales manager, and representatives from ISD, TSD, VPD, and Federal. 






The sales rep jumps out of the driver's seat and starts waving his arms and 
yelling for help. 


The systems engineer says he saw something like this when he was in Palo Alto. 
He says he'll call the other SE who was with him and see what she thinks. 


The field engineer gets out of the bus, jacks it up, and swaps all the tires out to 
determine which one is flat. 


The corporate marketing rep gets out, looks the tire over, and begins to forecast 
when the next flat will occur. 


The corporate controller informs everyone that there isn't enough money in the 
budget to buy a new tire. 


The manufacturing rep looks at the wording on the side of the tire and informs 
everyone that this part number isn't in stock. 


The Webo engineer gets out and says, "If you let me hire another person, | can 
build you a new tire in six months." 


The NDG engineer says, “I can build you a cheaper tire in five months, but it 
won't fit on that standard rim." 


The software development manager informs everyone that AOS/VS couldn't 
support a new tire until rev 12. 


The German sales rep looks at the tire and says, “This tire doesn't meet DIN 
standards, it needs amber lettering.” 


The programmer from diagnostics ponders the tire for a few minutes and says, 
"Yep, it's flat." 


The DAE test engineer turns to the programmer and says, "Well, don't look at 
me; we didn't sign off on this design." 


The PFA person looks at the tire, shakes his head and says, "You realize this 
will adversely affect your shrinkage costs." 


The business planner tells everyone that the bus can get by with only three tires. 


The corporate PR person hastily calls a press conference to inform the analyst 
community that this is just a temporary flat that will have no adverse affect on 
earnings for the quarter. 


The VPD rep says he knows a dealer that sells the same tire at a 35 percent 
discount. 


The TSD rep says he can't forecast the need for a new tire unless DEC announces 
one first. 


The ISD rep says he can't forecast the need for a new tire until CEO comes 
back up. 


The Federal rep says he can't support the purchase of a new tire unless the 
treads are made of fiber optics and TEMPEST-certified. 


The sales administrator says that any order for a new tire would be unprocessable 
without a unique CPU identifier. 


Finally, just as they all agree to use the spare, the business planner says, “Wait 
a minute! You can't change that tire, I don't have the correct paperwork!” 


To which the regional sales manager replies, “The hell with it, let's walk to the 
bar.” 
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Independence 
Day 


John closes on new house. 
Sleeps on floor for two months. 


Austin hits milestone, 


DASHER/One announced. 


Pubs group picnics at Hopkinton. 


Devon and Marty join Charlie's project as microcoders. 


Mark F. visits Grand Canyon 
en route to Motorola. 


, Kevin under pressure; Jay M. getting restless. 
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\N EW GENERATION 


In July, if you worked in R & D at Data General, it was possible to convince yourself that every other business 
had ed out the lights except yours — most schools had shut down for the summer; a quiet had descended 
over the auto industry as it retooled for the fall; the iron and steel industries had closed their process plants for 
preventive maintenance; and the U.S. Congress was on vacation. The building of the new product line kept 
developers busy night and day, and when that still wasn't enough, more than 140 new recruits joined in the 
effort, all of them fresh out of college. 
































On their first day the new hires saw a video about the corporation, heard their benefits 
explained, and had their pictures taken for their DG security badges. In a week they 
knew where to find the cafeteria and how to use the company's software tools. And in 
a month they all had projects — maybe not designing whole CPUs or file systems, but 
doing things that were indispensible to the bottom line of building and shipping computer 
systems. 


Data General isn't the first to take new college graduates and give them responsibility 
— years ago Seymour Cray recruited a few graduate students to build the first super- 
computer because “they weren't experienced enough to know it couldn't be done." But 
it is probably true that college talent represents a greater percentage of Data General's 
R & D work force than any other company’s. 


Its young organization poses some unique questions for DG management. How do you 
retain this population after the adventure of first responsibility has worn off? And how 
do you train them for the likelihood that they'll be making major corporate decisions 10 
years earlier than in traditional industries; or managing a team of designers before 
they've even had a child — a big change from the days when people practiced on 
unsuspecting tots before tackling bright, aggressive adults. Some of the managers we 
talked to conceded that there are no textbook answers. Others felt that they were in a 
sense pioneering the issues for the rest of the industry. But all of them were very clear 
about the importance of this year’s college hires: as one manager put it, “Without them, 
we wouldn't have had a product line." 





A YEAR IN DEVELOPMENT 


49 
























































A YEAR IN DEVELOPMENT 


50 








WHAT A NEW GENERATION 
THINKS ABOUT DG 





We know what the new college hires mean to their managers and the corporation — but what does Data General 
mean to them? We asked an engineer who, as of July, had been here about a year-and-a-half — long enough to have 
formed some definite ideas on the subject — to talk about the transition from college life to life and work at DG, and 


what she expects from the future. 


Can we start by talking about where you went to 
school, how you came to DG? 


I went to the Rochester Institute of Technology. I was 
working towards a degree in Computer Science but 
realized in my junior year that I wanted to do elec- 
trical engineering instead. By then it was too late to 
change majors so I graduated in Computer Science, 
but also took as many hardware courses as | could. 


I wanted to do hardware, or at least low-level soft- 
ware programming, but all my interviews were for 
higher-level software programming. When DG called 
and told me I'd be interviewing with Central 
Processor Development [CPD] I almost fell off my 
chair — I was so excited because it was a chance 
at what I really wanted to do. The interview went 
well, they sent me an offer the next week, and I was 
working here the week after that. And it was hard- 
ware! DG gave me a chance, they took a big risk. 


When you were interviewing, was the career op- 
portunity your first consideration or was it the com- 
pany? 

First it was the work I was going to do, then the 
company. I was looking for something where you get 
responsibility for a project in a short amount of time. 
I'd just spent five years in school and didn't want to 
spend the next year in manuals — I wanted to do 
something. Here they said I would, and | have. | 
also wanted a good location and at DG you're close 
to both the city and the country. For the first year I 
lived in a little house with a white picket fence, a 
horse across the street, a lake down the road, and 
I was four miles from work. 


When I went recruiting at colleges this year the 
students asked a lot of the same questions I did — 
like housing, does DG help you find a place to live. 
Some of their other questions were on how much 
responsibility you're given and the size of the groups 
you work in. And they were pleased to hear that we 
work in groups of two or three — five is really a 
large group. They also asked about the average age 
in CPD — we looked attractive on that point. The 
average age at DEC is over thirty — everyone goes 
home at five and no one wants to get together and 
do things after work. Here we're very young. That's 
a plus because people getting out of college want 
to be in a comfortable environment where they can 
find new friends. There are always events being 
planned such as white-water rafting, canoe trips, 
skiing, theater, baseball, wallyball, and parties. 


What were some of your expectations when you first 
came to DG? 


I didn't really know what to expect other than that 
it was hardware and I'd enjoyed that in school. It 
was a challenge because | really didn’t know that 
much so every day was a lot of learning. I never 
left school. The lab was like a great playground. You 
go in there and do anything you want, the resources 
are endless. If you need certain parts, if you need 
tools or scopes ... There was always someone there 
to help. You can go up to anyone and they can help 
you out one way or another. 


Was there any formal training or orientation? 


Not beyond the first day, which everyone goes through. 
In my department the first thing they said was ‘Here's 
the system, here are some manuals, this is CEO, 
learn CEO.' So I came back the next day and said 
I knew it and they gave me some more. There was 
orientation when I asked for it. I kept on badgering 
them ...'Tell me more about this ECL stuff.’ Morgan 
was a big help. He spent a few hours every day for 
a week telling me the theory behind ECL. You have 
to go out and get it. Everything wasn't handed to 
me on a silver platter, but that's good. If I wanted 
that I could have gone to IBM. 


What about the projects — what did you work on 
first? 

They gave me the spec on some firmware and wanted 
me to write some 8031 code to control the timing on 
a video board. It was kind of a lull period so I also 
did benchmarks on some projects they'd already 
finished. Then I went into gate arrays. I did test 
vectors for the arrays — it's not thrilling and I hope 
I never do it again, but it gave me insight into gate 
arrays. Until then I never knew what a gate array 
was, but now I could design one if I had to. Next I 
did a bus interface change for the Daiquiri [graphics] 
board. And now I'm working on a hardware interface 
for laser printers and scanners — it's something that 
I'm just learning about and it's a real challenge. 
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Can you go into that, the technical challenges in 
your work? 


The project I liked best was doing the bus interface 
for Daiquiri. I'd been after my manager for a long 
time to let me do a board design. I think he got sick 
of listening to me so I got the project. It was small, 
just enough to give me good practice without being 
out of my reach. There weren't a lot of ground rules 
so I was able to do it my way. | feel more confident 
about my design work now, and it was neat to have 
done the whole thing — to put it in the system, get 
it through PC, see it go through manufacturing, and 
support it once it comes out. It's been a lot of fun, 
and it's something with my name on it. Now I want 
a full board. You can take a lot of grief for it, but 
it's worth it. 


What do you mean? 


Well, if it's not working you hear, ‘Michele, your board 
isn't working.’ Then you say, ‘What do you mean? 
It's not the board, it's the microcode.’ (laughs) 


What are some of the projects that you'd like to go 
on to do at Data General? 


I'd like to either have my own board or work with 
another person on a very difficult board. Just to know 
that I can complete a difficult design all on my own, 
from scratch. Another thing is that I want more re- 
sponsibility — to move into management eventually. 
I don't want to do design work forever. It's not that 
I have any strict year-by-year plan, but within five 
years I'd like some sort of management position. 


Can you sum up your experience since you've come 
to DG — what some of the highlights are in terms 
of what you've learned? 


Electrical engineering is very demanding and selec- 
tive. You don't need a lot of engineers on a project, 
the teams are very small. So I feel lucky to have 
gotten into the niche of electrical engineers because 
everyone else depends on them. It's exactly what I 
wanted to be doing, and I'm constantly being chal- 
lenged by it, I'm constantly learning. The time that 
I stop learning is the time I'll probably change jobs. 
After a year-and-a-half I still look forward to coming 
to work because there's always something going on. 


51 


To AAG A CT om Ge Ray GPE, ED TA A GD RR Ee A SEA ERI ONT RY Mk PONY ae 

SF FMS Ae Te BR eS FS ES Sts a DPS POG SA RAL ie es na 
‘ BE Nong ES a, 

yee Teg 


FF THE 


In development the office decor doesn't always show decorum, but it does tend to 
lighten things up a bit when the company starts taking itself too seriously. The 
he walls of work areas in Westboro and RTP. 


A 
ae 


Pod E53 
Sind, 


nS 
~~? 
tate 


SE Rb 


"2. 


~2 Yesterday's Technology » : 
Strikes 3 


Be nate 
a> +P? ¥ 


aS 
= Pts 


“ 


oe 


} The brightest 
> mnewidea a 
in carpet care. 


With aay, 
Oe 


8 


oe 


= 
Te Mery 
toa 





ek 
ve 


+ 


Secs 
BS 


RR 
Me: & k 


ree: 








Yes... Youve seen cf hefeore- 
Mow Come vf with an exg lainaheon 








l. Gate Count Frozen bt 


Cfexsia | : , 
2. Mur-nows flash "hie Cosechetrrscesy fo be fumal on 


2 The Cold, Icy stare 


4 What do you lansun, you want Me fe clelete - games file ¢M 


Ss LT hive # cmiall dew deaf problem. 
lo. The Competer's Cooling system és broken again--- + ° 


, heere a, 23 
Z Cache conrtrlles moy uct assert “Free” wake SPC> are pacad on Hehes ne 


gy be 4 cold dey in OG before ---- 





3 Peal prosyenweys Oov't vse spate heatevs 
lo. Exeuse me lout Could you please close the window ? 


gt eee ee 
eee ae a cot 














vi 4 NRE AE RACERS RAS EOE ECU EES i" 
BEST sR) OT NESE RST Dy PAL Ee SE WEST: Me EHO CO Ao RID SS eae 





52 A YEAR IN DEVELOPMENT 











pis wut & EAD TAM Re. 















rita is a i 
EMER a Oped 
+B RON Ht A eT 


CrPTin Contest 





1. Please Siyn His patent Rele Ase Loam. 
2 Peat wey, of corse Wl 1 be! your 
pe a” 7 near 
3. Frermic’ "“Ypy sant Some ne eq upeedt TL 
Senha sh il 
ST Ae Wee 70 EMO THE (OVE 


i 










Careers a generation ahead. 








\ 





at 


Wat Do you MEW, CED 2. [I Is 
A Grr oF A Mess C 
i. 


f 





Who Fived the documertarian &? 






















What Theyre out of taco shells! 2 


Ritts 


= 














— 


aed a 


Bu1W6 DATA 
Raat 


CAL RM ata 
dated 5 5 rab” bo 


WHAT 22 we fesnuc 


* bs ‘ bt 
WEA Se boty ees 


4K 
my 
: 









|. OF ours this guke orn is fost envuyh fo yun Me Thos # 


a Amost payected, but we sti // neeL to Woe k on the “Lexie. 
Sl]ime Lyacl MCC hens m 
3 But just think of whaf you can 


SA AS 


do with 6000 gates, 


ae 


L the heat Smk noodsa litle wok _ 


BOE MPO YOY Tie SE A FEOF EY Ak: 
SOE OSS hos CORR A 





Foe 






A YEAR IN DEVELOPMENT 53 








POWER ENGINEERING 


For about a year now, every Thursday at one, the Viking program meetings had opened with a report from the program manager 
on the progress of the central processor. As the summer wore on, this report began to resemble a kind of litany centering on the 
status of the Viking ALU. The status of the ALU was that it was broken; the response, always from the same quarter, was, "When 


can we run AOS/VS?" 


From another quarter came a report on the Viking power supply, and it, too, was becoming rather predictable. So steady was 
its progress, you might have thought it was simply another black box that could be engineered blindfolded — rather than the 
high-risk new technology venture that it really was. This initiative, the first commercial application of high-frequency, distributed 
power regulators using hybrid ICs, was led by a relative newcomer to DG, a man who had worked a quiet transformation in the 
Power Systems group since becoming its manager a year before. In the following interview he explained this technology and the 


challenge of building it into Viking. 





Could you start by telling me about your back- 
ground ... I think you came from DEC ... Did you 
do the same kind of work there? 


Right. I got involved in power electronics in 1968 
when I started graduate school. I worked with Pro- 
fessor Wilson at Duke University for a number of 
years, got a PhD in power electronics, and have 
been working in the field ever since. I spent some 
time at Bell Laboratories and then at DEC, where | 
started a research group in power electronics. 


What made you decide to come to DG? 


At larger companies, particularly when you reach 
the middle management level, I think there's a tend- 
ency to get sidetracked by organizational or political 
issues. It's much harder to sustain the kind of intensity 
needed to seed and follow through on new design. 
I was looking for that intensity; I wanted to focus on 
getting something done, and Data General seemed 
like a good environment for that. 


So did you have any goals in mind when you were 
coming here ... any objectives? 


I guess the reason I came to Data General — the 
reason | even listened to the opportunity here was 
that I had met some of the people in the DG power 
group at conferences and was impressed with them. 
They were very bright and seemed to be really on 
top of power supply technology .. and that attracted 
me. To me what's attractive is really knowing your 
field and being able to do the best in your field. And 
the handful of people I had met clearly demonstrated 
that ability. My goals have always been to do ex- 
cellent work and I felt there would be a nice op- 
portunity here. When I got here, I was very pleasantly 
surprised to find that nearly everyone was very good 
in the field, something I just never expected. It's 
unusual to see such consistency of excellence in 
people in one organization. So having really good 
people has made it, I can't say easy, but certainly 
possible to do the best work. And I think we really 
are doing the best power work in the business. 
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I understand that since you came the power group 
had made a major turnaround. And I'm wondering 
.. given what you said about the good people here 
before you, how that happened. Was it leadership? 


Yes, I think it's leadership. One clue I had was that, 
after I'd been here a while, people would tell me, 
‘Wow, it's only been since you've come that we've 
realized how good we are.’ Actually, it was just a 
matter of helping them see what's out there, what 
others are doing, and how we're really doing more. 
It's not a sell job, or a way of tricking people into 
thinking they're better than they really are. These 
people really are the best. All I had to do was show 
them. 


Getting into the MV/20000 power system itself, I 
know it's something unique and different, but I don't 
know what technologies are used ... 


If you look at it from a total systems point of view, 
there are several pieces of the MV/20000 power 
supply that stand out: some of it new technology, 
and some of it a clever application of older tech- 
nology. Most systems use a bulk power supply that 
plugs into a wall and puts out 5 or 12 volts to the 
pe boards. On the MV/20000 we moved towards the 
“distributed regulation" power systems architecture 
with a two-stage design. 


The first stage rectifies the ac line to a semiregulated 
dc voltage — on the MV/20, it's a 55-volt de bus 
semiregulated. That piece — the ferro-resonant trans- 
former — is relatively old technology, and yet it's 
intelligently applied here because it's a very low- 
cost, rugged front end for a power system. Most 
minicomputers require the customer to buy separate 
power conditioning equipment to protect against line 
transients. The MV/20 doesn't need that, because the 
transformer already has a lot of line-transient im- 
munity built into it. 


So that would save space and cost... 


Right. The additional power conditioners are fairly 
expensive for manufacturer and customer alike. Now 
in the second stage ... and this is where the new 
technology comes in ... we need to convert 55 volts 
to the lower voltage requirements of the CPU and 
I/O functions. To perform the conversion we devel- 
oped a set of regulators with a very low profile and 
high power density: we've achieved 6 watts per cubic 
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inch on each 7 1/2- by 15-inch regulator card, com- 
pared with an industry norm of about 2 watts per 
cubic inch. And the way we did that was, first, to 
adopt a high-frequency conversion scheme, with each 
regulator operating on the order of 350 kilohertz. The 
high frequency allowed us to use smaller energy 
storage components, instead of bulkier, less concen- 
trated ones. Secondly, we used hybrid IC packaging 
techniques; by that I mean the individual resistors, 
capacitors, semiconductors and so forth could be 
reduced and packaged together in thick film hybrid 
modules. So the overall power system is smaller, and 
more reliable due to fewer working parts. 


Who makes those hybrid components? 


We worked with a company called Centralab, and 
another called Gentron, and we continue to talk with 
others. We want to develop some good long-term 
relationships, come down the learning curve, and 
make these things cheaper and cheaper because we 
expect to continue using this technology in future 
products. 


So you're part of their design team ... you input 
what you'd like ... 


Right. It's a very interactive design. We give them 
a circuit schematic and performance characteristics. 
Then they implement that circuit with their hybrid 
technology. The vendor lays out the circuit on a little 
ceramic substrate. On the MV/20, where we were 
using very high frequencies, the layout was as much 
a part of the electrical design as the choice of com- 
ponent values. We worked iteratively with the vendor 
through this phase to come up with the best design. 
It was very definitely a partnership — their knowl- 
edge of the process, our understanding of the circuit 
performance. 


Other companies must be aware of this technology. 
Why were we the first to use it? 


Of course, our major competitors must be making a 
similar effort in their own product lines, but they tend 
to be slower; we did this very, very quickly. It's really 
a matter of people looking into the future for some- 
thing that's not there today and recognizing that it 
can be done, and that there are benefits to doing it. 
A lot of people can't do that — they can only copy 
what's here today. 











It sounds risky. 


Oh, it's very definitely risky, and a lot of people 
would rather avoid that. But then, life is boring without 
risks as far as I'm concerned. (laughs) I don’t mean 
that I'm out there looking for cheap thrills ... I don't 
have, you know, a death wish or anything! But I'm 
going to take risks that I feel I can pull off. Stretch 
goals. 


I've heard from Tom [West] that when you tried to 
sell this new technology he wouldn't go for it — he 
thought it was too much for the MV/20 program to 
take on. But you went ahead and did it anyway. 


Yes, that was a tough sell because Tom was looking 
at ... I don't want to put words in his mouth ... but 
thinking back on it, it seemed to me that Tom was 
looking at the MV/20 as the next step beyond the 
MV/10000: take the MV/10 and shrink it to one board, 
double the performance for about the same price; 
and do it fast. So why mess around with a new 
power system? 





We felt that we could contribute to the overall appeal 
of the product by making the leap to the new tech- 
nology. We could've gone with the existing power 
system but we would have lost the benefits of this 
new system — such as configuration flexibility. The 
customer doesn't have to buy the whole power system 
up front for a minimum configuration, he can just 
plug in these half-height regulator cards whenever 
he's ready to add more options. And less of the card 
cage is required now: there's room for an additional 
six I/O slots because the new power system's smaller. 


Tom never disagreed about the value of these attri- 
butes to the system, only about when to introduce 
them. He would have preferred to fold it into a future 
product. But we kept saying that ‘Well, you know, 
we really think we're close enough to build this thing 
without putting the rest of the program in jeopardy.’ 
We felt that the risk-payback kind of thing was in 
our favor so we kept hammering away and encour- 
aging him to trust us ... and he finally gave us the 
nod. 


So you did get the support you needed? 


Yes. Although I must say it was a bit uncomfortable 
for a while because we knew if we didn't come 
through we really should be hung. The risks person- 
ally became very great, because this was the first 
commercial application of a new technology: if we 
didn't make it, we could have done serious damage 
to the program. 


What kind of time frame were you working under? 
I'm not sure where you were starting from ... 


OK. Here again is where we talk about risk .. but 
not unreasonable risk. I like to do technology research 
up front before commiting it to a product. When you 


get to a point where you understand the technology 
well enough — when you know what the sourcing 
issues and unresolved problems are — then you have 
a big enough handle to decide whether or not to go 
forward. 


Depending on how it goes ... Sometimes you can get 
to a point where you're very comfortable with your 
research before it's needed and then it's easy. Other 
times you've got a product requirement that comes 
along, you're not quite finished with the research, 
and you've got to make a call. Do we want to take 
the risk of cutting it in now? That was the question 
for us on the MV/20000. 


In this case, | went around the world talking to 
vendors on hybrid technology, and | had done pro- 
totype power supplies in different power ranges. I 
knew that we could go in a fairly straight path and 
not go down any blind alleys. So we were able to 
do this pretty quickly — it took on the order of a 
year to put this thing into a real, working prototype, 
and be ready to introduce it into the manufacturing 
facilities. 


Can you talk about a few people in your group who 
were instrumental in the new power system? 


Yes — | don't want to leave anyone out, but very 
definitely there were some key people. Let me men- 
tion first the project engineer. Uli is a very thorough, 
meticulous engineer who leaves no stones unturned. 
That's the kind of guy you need on a job like this 
because if you don't turn over all the stones you 
know that there's something under there that's going 
to bite you later on. It's a good feeling when Uli 
goes down the path and there's a rock because no 
matter how tired he is, he’s gonna get down there 
and turn it over. He coordinated the circuit devel- 
opment, working with the vendors; he really under- 
stood the power system architecture, and then the 
circuit design using the hybrids. 





Another very key person on this was the project 
manager who came in when things were about as 
hot as you can get ‘em. I asked John to step in when 
we were already committed on a course — a really 
tough position because we'd taken the risk, we'd sold 
the idea, and now it had to work. John is committed, 
a hard worker and extremely talented. He jumped 
right in, looked at what we had, and immediately 
made some corrections on course. Over a one or two 
year period he had done research on the high-fre- 
quency circuits we were using in the MV/20 regu- 
lators ... so while I knew the hybrids, John was on 
top of the circuitry and Uli was pulling it all together. 


It was an extremely efficient and focused operation, 
with very little in the way of mistakes and false starts. 
We were just going full steam, and we stayed right 
on track. 


A YEAR IN DEVELOPMENT 


Sounds like material for a new book, Soul of a New 
Power System. 


(Laughs) And it's fun and rewarding. Of course, there 
were times when the pressure was on and we were 
sweating pretty hard ... I can remember some dis- 
cussions where we said, ‘You know, we could have 
taken the easy way out. Maybe it’s not too late to 
turn back ...’ But there's the personal satisfaction. 
Having pulled it off, we really feel good about it. 
Had we done it the easy way | imagine it would 
have felt okay — there'd be no danger of hurting 
the product, although we wouldn't have helped it 
much either. But then, there would always be that 
nagging feeling that we'd chickened out. 


So you feel you're contribution has been recognized? 


Yes, definitely. We've had good pats on the back. 
And having the recognition helps in a lot of 
ways — for instance, in building a close working 
relationship with the Central Processor Development 
group, where they trust us because they know we 
can do the job. That's important because you can't 
develop a power system in a corner, as a black box 
that you just hook on. You've got to be part of the 
overall system development team, and we really are 
now. Without that communication and trust, you may 
do things one way and find out later that they should 
be different. With Jim [the program manager] keeping 
us hooked into the MV/20 program, we were able 
to put all our energy into getting it right the first time. 


One last thing. Your personal impressions of the 
philosphy of DG design as opposed to other places 
you've worked. 


Sure, I've found some significant differences. First, 
everyone wants the best people working for them, 
but Data General really does something about that. 
Data General can attract the best people because 
we do the best work — and | think excellence tends 
to attract excellence. The other piece of that is, we 
also let you know if you're not one of the best, if 
you're not contributing. 


Another difference I see is that Data General is far 
more aggressive on schedules. I like that aspect, 
although I don't want to carry it to the extreme of 
putting something out there before it's ready and 
shooting ourselves. Obviously we're fighting for mar- 
ket share, while DEC and IBM have a tremendously 
large customer base that will just sit around and wait 
for them to deliver. Our schedules and our design 
goals have to be aggressive if we're going to win 
people over to our products. Clearly, I prefer that 
aggressiveness. I prefer doing the best products, and 
I feel good that we've got them. 


There is one difference that I wish didn't exist ... a 
visibility issue. As a smaller company, we may get 
a short paragraph from the trade journals when we 
do the best there is, while DEC or IBM can command 
pages of coverage for their ho-hum stuff. It's enough 
to make me want to go out there and start making 
sales calls! Personally, I'd like everyone to come over 
and see what we have. When you do this caliber of 
work, and put out this caliber of product ... you want 
the whole world to know. 
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% oy 7 ! Attempt to boot /VS on Opus — penguins don't fly. 


Bubble generator arrives in Westboro. 


DG and AT&T certify System 85 PBX with ECLIPSE MVs and DASHERs; 
DESKTOPs get new high-density memory boards. 


Joe W. builds new home. 


Datapro rates DG systems high 
in overall customer satisfaction. 


DG/UX and MV/UX integrate System V, Release 2 Version 2; 
CEO interfaces with IBM, supports DIA/DCA protocols; 
intelligent broadband controller introduced. 


Ultrix problems cause hold 
on microVAX shipments. 


Viking prototypes 
delivered to CPD. 


Birthday: CC Jackie's last day. 
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The drawings of Opus are from PENGUIN DREAMS AND STRANGER THINGS, A Bloom County Book by Berke Breathed. Copyright © 1985 
by the Washington Post Company. Reproduced by permission of Little, Brown and Company All Rights Reserved. 


A YEAR IN DEVELOPMENT 








PEACEFUL COEXISTENCE 


The world of R & D can be quite insular and private. It focuses with great intensity and in great depth on the 
development at hand, often to the exclusion of anything else on the sides. Perhaps this is why, by the late 1970s, 
many companies found themselves with large gaps or incompatibilities among their own products. And why, blinded 
by the notion of proprietary technology, nearly all of them had built whole product lines with no provision for 
communicating with the rest of the world. 


In those days “software locking" was an accepted way of getting and keeping business. But since 1980, with the 
emergence of industry and defacto standards backed by a mature user community with the power to enforce them, 
vendors in every computing sector have had to rethink their strategies. Each has had to decide whether to circle the 
wagons around its proprietary architecture and stand alone, or to accommodate other architectures and stand among. 


Data General's decision — to pursue an open, flexible architecture — came easily, and of necessity as much as by 
choice. Historically smaller in size than its major competitors, it had been coexisting more or less peacefully with other 
companies’ operating environments and gear for years. Long before others it implemented MS-DOS, PC-DOS, Unix, 
LISP and ADA in addition to its proprietary AOS/VS. Now these environments were growing with the rest of the 
product line and becoming increasingly integrated with it. In the following interviews we looked in on the company’s 
PC and Unix development efforts, which were evolving in some interesting ways. 





INTEGRATING THE PG 





It is somewhat understandable that the fervor of invention would breed a certain myopia among early computing enterprises 
about their place in the American industrial culture. But it's a little surprising that the start-ups of the ‘80s didn’t learn more from 
their predecessors’ mistakes. By 1984 hundreds of companies had followed Apple and IBM with PCs and intelligent workstations, 
most of them point products, few of them compatible, and hardly any of them connectible to other micros, minicomputers or 
mainframes. Now large corporations were looking for ways to tie it all together in something resembling a coherent computing 
context. This is the problem one program manager was working on in August. In the following interview he gave us an overview 
of DG's strategy in the PC integration area. 





Could you start by telling me what PC integration 
is, why it's needed ... 


The underlying concept is to integrate personal com- 
puters, be they ours, IBM's, or IBM compatibles, into 
the DG product line. There are millions of IBM PCs 
already out in the marketplace and they're in all the 
major accounts that we serve or would like to serve. 
We feel that the vendor who acknowledges the value 
of those PCs can provide significant value by inte- 
grating them into a company's overall computing 
environment. 


The reason for having an architecture that connects 
PCs and MVs together is to benefit from the best 
aspects of both machines. PCs have been very suc- 
cessful because they offer users total control over 
their own computing environment, fast interactive 
screen and keyboard responses, and secure own- 
ership of information stored on a local disk. The things 
that make timesharing minicomputers like the MV/ 
popular are their compute power, large shared-disk 
storage, tape backup, a broader range of input and 
output devices, more powerful communications so 
you can hook up a network that spans the globe, 
and connectivity to corporate mainframes. 





How did you go about implementing a PC inter- 
connect strategy? 


We decided to go for a phased approach. This would 
get us to market quickly, but give us time to add 
industry and defacto standards as they became sta- 
ble. And it would allow us to manage the complexity 
of bringing together a lot of hardware and software 
components into something customers would perceive 
as a thoroughly integrated and easily implemented 
solution. 


A YEAR IN DEVELOPMENT 


The first phase was CEO Connection rev 2. That 
gave us a general-purpose terminal connection and 
file transfer mechanism to the /MV for PC software 
such as CEOwrite or third-party packages like Lotus 
1-2-3. We also expanded our CEO integration with 
terminal emulation on the PC, so people could use 
their PCs, DASHER/Ones or DG/Ones as CEO ter- 
minals. From a CEO menu you could now mail a 
document created on the PC over to the MV/, where 
our software would convert it to CEO format. Similarly 
with filing: you'd see a CEO menu on the PC screen 
that lets you work with the CEO filing system on the 
MV/. 
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Obviously, you could extend this in a number of 
ways. Can you talk about the direction you're taking 
in general terms? 


Whereas our focus was initially on connecting PCs 
with MV's to run our proprietary applications, like 
CEOWrite, we now want PC applications to be able 
to take advantage of the CEO environment and the 
services on MV/ systems. 


To get there, we need to look, number one, at the 
type of interconnect between the PC and the MV/; 
and number two, at the kind of communications soft- 
ware services that would allow a PC to use the 





services of an MV/ for file services, printouts, and 
so on. In both cases, we'll want to accommodate 
those emerging standards that appear to have long- 
term merit in the PC networking world - so that the 
customer can build spreadsheets on his PC and store 
them or print them out on the MV/ system, without 
requiring a special version of the PC spreadsheet 
application. 


There is some work in communications hardware 
needed to allow each node to participate in the 





network, whether its a DASHER, a DASHER/One, a 
DG/One, and IBM PC or PC clone, or an MV/ 
system. 


Ultimately, we'd like to cleave applications so the 
presentation services run on the PC, taking advan- 
tage of the fast screen response. And those pres- 





entation services should conform to a_ standard 
windowed user interface, compatible with the overall 
CEO environment. That, I think, would be as close 
to an industry-standard distributed systems architec- 
ture as anyone could come. 


What are some of the critical technical issues that 
have to be resolved in integrating PCs with other 
environments? 


Most of the issues come from the fact that in an open 
architecture like this we have to guarantee compat- 
ibility with the industry standards and be able to run 
as many third-party applications as possible. Working 
in a standards-compatible environment means it's 
harder to be creative. But it's equally hard to be truly 
compatible — frequently we find that applications 
are dependent on undocumented features of the sys- 
tems we're trying to be compatible with. So tracking 
down problems is a real detective story and requires 
cooperation between a lot of different groups. 


Another issue comes up when there's a conflict be- 
tween industry standards and the standards we apply 
to our proprietary products. Some of those are very 
tough decisions to make because many of the goals 
behind PC integration are to attract new busi- 
ness — we want to come up with products that 
existing PC customers feel comfortable with, yet at 
the same time not short-shrift our CEO base. 





A YEAR IN DEVELOPMENT 


Can you compare DG's strategy in this area with 
that of micro vendors, other minicomputer compa- 
nies, or IBM? 


The micro vendors don't have any large computing 
environment to integrate PCs into, so they're simply 
trying to supply “glue” components. We believe that 
most large corporations are looking for a more com- 
plete solution. IBM doesn't currently offer any real 
integration, so the minicomputer vendors seem to be 
in the best position to provide an acceptable solution 
for customers wanting to tie PCs into their corporate 
computing facilities. 





I think one of the key things for DG is that we're 
building on our commitment to following industry 
standards. We can offer the broadest compatibility 
by building each component on the key relevant 
standards for it. DEC, for example, appears to be 
going more down the path of extending their pro- 
prietary architectures out to the PC. We're following 
the path of an open architecture and an industry- 
standard architecture. 


think that distinction is important. Our solution should 
give customers the benefit of our proprietary strengths, 
particularly in the office automation area with CEO, 
while respecting their desire for vendor-independ- 
ence. Our intention is to win on price-performance, 
cost of ownership and connectivity — not on software 
locking. 


























THE EMERGENCE 


OF UNIX 





A lot had changed for DG's Unix development group since that party at the Hotel Europa last winter. In August the company 
announced another release of the operating system. Meanwhile, more ambitious enhancements were being planned to integrate 
distribution and multiprocessor technologies and to ensure conformance with AT&T's version V.3. It may have taken 15 years for 


Unix to evolve from an internal tool at Bell Labs, where it was invented, and become a popular platform for scientific applications; 


but now it was attracting new applications at an incredible rate. As a result the Unix group saw its product assume a more 
critical role in the company's development strategy. In the months ahead it was to become more important still. To find out how 
Data General's Unix environment evolved, we went to RTP and asked the Unix operating system and communications project 


leaders. 





What was DG’s first Unix product? 


Dennis (project leader for the operating system): 
We started our Unix program with a hosted product, 
MV/UX. It's integrated with, or runs on top of, AOS/ 
VS. We did that first because it seemed to be the 
best way to give existing AOS/VS customers some- 
thing they'd been asking for — Unix capabilities. 
And it was a quick way of geiting into the rapidly 
expanding Unix marketplace. 


One of the problems when you start out with a new 
operating system is building the range of utilities and 
languages that customers need to run or develop 
their applications. Doing the hosted product first al- 
lowed us to get on line with Unix quickly, without 
having to provide all the necessary ancillary software 
up front — compilers, database products, and so 
on — because they were already present on /VS. If 
you look at the set of software products that belong 
to /VS, there's a list a yard long. 


Our approach was to leverage those existing /VS 
products, and to develop our Unix expertise before 
we jumped in and did the native version. We finished 
work on the first rev of MV/UX and shipped it in 
late 1983. By that time our native Unix product 
[DG/UX] was under development. 





We adopted a similar strategy with DG/UX, using 
as much of the existing AOS/VS software as we 
could. What we did was to port the Unix operating 
system to DG hardware, and take the languages and 
language utilities for the system by and large from 
AOS/VS. It was a fast and economical way to get 
a full range of languages running under Unix; and 
it really gives us excellent compatability between 
AOS/VS and DG/UX at the language source level. 
We shipped the initial version early in 1985, rev 2.0 
followed later that year, rev 3.0 in summer 1986, and 
3.10 will begin shipping in 1987. 





What's the difference between a hosted Unix like 
MV/UX and a native version? 


Dennis: MV/UX looks just like any other program 
operating under AOS/VS. A native Unix runs directly 
on DG hardware and the file system has different 
characteristics, it's a simpler operating system. Also, 
the naming conventions of the file systems are dif- 
ferent — that can cause problems at the applications 
level. 


A YEAR IN DEVELOPMENT 


Keith (project leader for Unix comms): If the reason 
for having Unix in the product line is to expand the 
number of applications that can run on your hard- 
ware, you need a Unix system that conforms to 
industry standards: a native Unix. MV/UX is really 
aimed at our installed base of customers running 
applications on an AOS/VS platform who want some 
Unix capabilities. 


What communications software did we implement 
for Unix? 


Keith: TCP/IP was originally developed for ARPA- 
NET, but has become the defacto standard for com- 
munication among Unix systems. We implemented it 
under DG/UX while the Westboro communications 
group implemented it for AOS/VS. 


Dennis: The benefits of doing this in both operating 
systems is that it gives us an industry-leading com- 
patibility story across both environments ... a more 


complete picture in terms of the range of machines 
we can communicate with. For instance, | can have 
a network with an AOS/VS system, a DG/UX system, 
a VAX system, a Sun system and any other machine 
that also runs TCP/IP; and I can transfer files, do 
remote logons, and so forth. 
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Keith: The product also presents a unified user in- 
terface, so it looks the same on an AOS/VS system 
as it does on a DG/UX system. Our strategy, not 
only with Unix but across the whole product line, 
has been to try and provide customers with a con- 
sistent user environment. This implementation gives 
us a leg up on most vendors who go out and buy 
third-party TCP/IP packages that aren't particularly 
consistent. 


What are the difficulties you face when you're en- 
hancing an industry-standard product like DG/UX? 
Do you find that you want to go against the stand- 
ards? 


Dennis: Sometimes. Sometimes you're committed to 
features of Unix that you might want to change if 
they were in AOS/VS. The fact is the proprietary 
product belongs to you — the definition of the product 
belongs to you — but with Unix the definition belongs 
first and foremost to AT&T because they generate 
the Unix product. But it also belongs to the Unix user 
community and to Berkeley. And then there's an IEEE 
standards effort to define what the Unix standard is. 


Keith: A significant development problem stems from 
the commodity nature of the Unix market: customers 
buy Unix for machine-independence. With AOS/VS 
and Xodiac you always know that there’s DG hard- 
ware and software at the other end of the wire. With 
TCP/IP you don't know what's on the other end — 
it could be a DEC machine, it could be an AOS/VS 
machine, it could be a Sun workstation. So we have 
a very interesting testing problem because of foreign 
systems. There's always a fear that some manufac- 
turer will implement something a little bit differently 
and that those systems won't talk to ours. We have 
to do quite a bit of bullet-proofing to make sure we 
can talk with any TCP/IP implementation. 





What has your development focus been this year? 


Dennis: Our first objective was to close the gap with 
Berkeley compatibility. So we made DG/UX rev 2 
compatible with the Berkeley 4.2 standard as well 
as with AT&T System V release 2. 


Next we needed to support the Viking and Bulldog 
programs [in DG/UX rev 3], as well as Guss in the 
technical workstation environment [in DG/UX rev 


3.10]. 


Keith: The Department of Defense has basically de- 
creed that TCP/IP will be the standard for all DoD 
communications between computers on the Defense 
Data Network [DDN]. So we spent most of the last 
year working on making our version of TCP/IP fully 
compliant with DoD specs. We worked very closely 
with the Westboro communications group on this 
because they supply the link-level X.25 software — 
they've put a lot of effort into passing the X.25 cert- 
ification tests. At the same time we've been trying 
to make all the upper levels of the communications 
services software — TCP/IP, Telenet, FTP, and so 
forth — DDN-compliant. 





A YEAR IN DEVELOPMENT 





What about the features you're working on for 
DG/UX? 


Dennis: We want to stay on the power curve as more 
features are added to the Unix standard definitions. 
Our next major revision contains a significant piece 
of system software — Sun Microsystems’ network file 
system [NFS] — which will give our users a more 
distributed environment. They'll be able to intercon- 
nect a lot of different machines in a network and 
access files across the net in a transparent way. NFS 
has been very successful for Sun — they've been 
very active in promoting this product and signing up 
other vendors to port NFS to their Unix products. So 
we see it as a defacto standard. 


Of course we'll maintain parity with the standard 
versions of Unix ... but we also want to provide 
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significant value-added, to give customers compelling 
reasons to choose DG as the platform for their Unix 
applications. Among other things, and we want to 
add industry-standard windowing capabilities for our 
workstation hardware. This is just the first step toward 
building a software environment to exploit worksta- 
tion capabilities. 


Is there ever a debate about what's going to become 
industry standard? 


Dennis: Constantly. There’s real tension between 
trying to beat the competition and offering new func- 
tions, and in waiting to see what the standard is 
going to be. Distributed file system services is a case 
in point — because Sun has been so successful in 
promoting NFS, they've had a head start on just 
about everybody else. But AT&T, in its System V 
release 3 product, is introducing another distributed 
file system — remote file system [RFS]. Which of 
those will be the ultimate Unix distributed file system 
standard? I'm sure the AT&T people want to think 
that it's RFS. Sun and a lot of people who've already 
invested in NFS like to think it will be NFS. Ultimately 
in the standards business it’s the customers who 
decide. It's also sometimes possible for more than 
one standard to exist. 








Keith: Our approach is to do the best job we can of 
sensing what customers really need, trying to match 
that against competing standards, then applying our 
own sense of what constitutes attractive system func- 
tionality. We don't do this in a vacuum — we main- 
tain a high visibility in the standards community, and 
we keep very close to the user base. 


Have you ever made a bad decision in determining 
what standard to choose? 


Dennis: | think that remains to be seen: our product 
is only a couple years old. We think we've made 
some good decisions — for example, we made the 
decision to achieve both AT&T and Berkeley Sofware 
Distribution [BSD] compatibility. That's what the IEEE 
is starting to concentrate on now, and it's what the 
major vendors are just now trying to do. So you see 


a marketplace where Sun Microsystems, which offers 
a BSD 4.2 compatible Unix product, is talking to AT&T 
and trying to incorporate some System V features 
into their version. And AT&T is going to accommodate 
some BSD 4.2 functionality in their product. So in 
retrospect it turned out we did the right thing in 
combining functions from those two systems. We 
probably have one of the most integrated AT&T/BSD 
stories you can find. 


But are we making the right choices between com- 
peting standards? Really the marketplace will tell. 
DG/UX is still very young, but it won't be long before 
we win some big deals with Unix. And when that 
happens I think we'll have opened a share of the 
market that DG really hasn't been in. It's one of the 
most exciting things about Unix from my point of 
view. 














“If you look at the engineering or scientific market over the last few years, what's 
happened is that customers are buying different components from different com- 
puter vendors. And they have significant motivation to do that because in the 
lab environment you can't necessarily buy all the equipment you need — work- 
stations, a Cray, a good file server, a bunch of comm gear and the right software 
for your applications — from the same computer company. Some vendors come 
close, but in terms of the extreme needs a customer may have in these different 
areas, they have to go to more than one vendor and sometimes end up dealing 
with many vendors. 


“This has led to a trend where customers have standardized on things like 
operating systems, languages and communication protocols, heading toward an 
open environment. Open means that a lot of people can build products to fit in 
that space. So the customer can go out and ... It's like a supermarket almost — 
he can buy a Cray and an Alliant and some workstations and hook them up to 
DG's office automation and do a lot of wonderful things. 


“There's a down side to doing that however, because the customer is now the 
system integrator and has to resolve those headaches. But the solutions he's able 
to build are so compelling that it's worth doing, when you really can't get the 
range of solutions from a single vendor. 


"The other issue is the application platform — many applications are built by 
individuals and labs and third-party software vendors. If you put yourself in their 
shoes, there's really no question that you should target your application toward 


A DIRECTOR'S VIEW 


Some time after we talked with the Unix managers, a new director joined the software development 
community, bringing with him a compelling view of operating system trends as they relate to Data 
General's position in the marketplace. This was his reading of what's been happening in the 
technical and scientific user communities and the role of industry-standard products such as Unix. 


this set of open technology components, because that gives you the broadest 
exposure in terms of who's going to use your product. There are now very few 
people who write applications just for a single proprietary platform. 


"So the technical community is changing to a standard platform. We're beginning 
to see the same trends in the commercial data processing world. It's really just 
a small toe-hold right now, but you can see some very fine database products 
running on Unix systems, and those are traditionally the underpinnings of trans- 
action processing and certain kinds of data processing applications. And we're 
beginning to see COBOLs offered by third-party vendors being targeted toward 
Unix platforms. 


“So it's happening. And I think the reason it's happening is that everyone, other 
than DEC and IBM who have enormous installed bases, is trying to understand 
the role they play in the industry — they want to maximize the number of 
applications their systems can run. 


“This means two things for Data General: First, we have a solid installed base 
of customers running their applications on AOS/VS. We have a large commitment 
to those customers and expect to follow through with a significant development 
investment in our proprietary platform for the foreseeable future. 


“At the same time, in the past four or five years we've lost ground in the technical 
and scientific side. This is why we need to aggressively develop an industry- 
leading Unix platform: so we can generate a contemporary technical product 
line that will allow us to compete more effectively in that marketplace.” 


A YEAR IN DEVELOPMENT 
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PEACEFUL 
APITULATION 


The old adage says if you can't beat ‘em, join ‘em. In the case of IBM, the company with the largest installed base 
in the world, it was never a question for Data General of trying to beat them. Instead, DG was the first vendor to 
recognize that in order to survive in an IBM-dominated world it would have to accommodate IBM and its customers, 
and by so doing, win business for itself. 








On the eve of DG's announcement of another first in IBM connectivity — an interface to IBM's DISOSS with support 
for DIA/DCA protocols — we talked to the manager of the IBM Communications development group. Here he talked 
about the integration of DG's product line with IBM's, both in philosophy and in reality. 


 ——————— 


First can you talk about your background? 


I joined the company in 1977 and worked in Design 
Assurance Engineering [DAE]. In 1979 I joined com- 
munications development, where | worked on the tail 
end of the RCX70 project and then started thinking 
about an interconnect to SNA — the architecture IBM 
uses to connect its own computers. I wrote up design 
specs and product objectives for SNA and built a 
small team. Ours were the first SNA products to be 
introduced to the industry. That was in 1980. 


After that I was looking for something new and in- 
teresting to do, so | went into Systems Engineering, 
and after that Product Marketing, where I managed 
communications products. I enjoyed that very much 
— and one of the things I was responsible for was 
the product requirements for IBM connectibility. One 
of the hot issues in 1982 and 1983 was what to do 
about interfaces to DISOSS! using DIA/DCA and 
LU6.22. I tried to come up with a product that would 
meet the market requirements. That was the begin- 
ning of the end of my career in marketing. 


Is that when you were asked to put together the 
proposal of how to do it? 


I put together a requirements document, and then 
we looked at trying to develop a product internally. 
We also considered looking outside to see if we could 
buy a software package that would get us there 
faster. 


We soon learned that it was very difficult to come 
to an agreement with anybody who had the tech- 
nology. I made an off-the-cuff comment in a meeting 
that it could probably be done internally at a rea- 
sonable cost. I was asked to put together a plan of 


| BM's office automation system under their MVS operating system. 
2 Protocols for exchanging files using electronic mail, and for con- 
necting to an IBM machine via other systems. 
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how that could be done — and J realized | should 
never have opened my mouth (laughs). 


I didn't pull the plan together until just before the 
Christmas party. I turned it in and went on vacation 
for three weeks. When I got back I had to present 
it to the Vice President of Information Systems Group 
Marketing, and the day after that it was presented 
to Bob Miller [Sr. VP, Information Systems]; and two 
weeks later I was told I was going to manage this 
project. That's when I became part of development 


What were the goals of the program? What would 
DG's Document Exchange Architecture [DXA] allow 
the user to do? 


The goal was to enable a user sitting at a CEO 
terminal to exchange messages, documents, and files 
with other users connected to IBM office systems, 
whether they were connected to DISOSS, sitting at 
a Display Writer [a standalone word processor], or 
a System 36 or System 38. 


How did you proceed from there? 


Once I was given the job of building this product I 
had to figure out what it was going to take in terms 
of types of people, hardware and software capital, 
office space, and so on. So | worked with our con- 
troller and set up a detailed budget. At the same 
time I was looking for some senior level development 
people. 


When the budget was signed off we went out to 
purchase an IBM system typical of the sort of en- 
vironment our product was planned to communicate 
with. We ordered an IBM 4300 and a Display Writer. 
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The documentation on SNA that's available in the 
public domain could probably fill a library, so you 
could read volumes on the subject, but in real life 
your product has to interface with real hardware and 
software — not an architecture. That's why the equip- 
ment was essential. You can't develop and debug a 
new rev of AOS/VS without running it on the 
MV/ systems it will support — for the same reasons, 
we needed to run our software on both MV systems 
and in an IBM environment. 





Was it easy to find people? 


Yes and no. At first it was very difficult to get the 
right level of knowledge. At that time it was impos- 
sible to get anybody who had any SNA experience, 
so going into the project I decided to look for bright, 
intelligent people with good systems experience. | 
managed to recruit an extremely competent group 
of senior developers that did phase one of the DXA 
program. 


What was the deliverable product for the first phase 
of DXA? 


For the first phase we implemented DIA, a primitive 
mail protocol which allowed us to do electronic mail- 
ing from an IBM mainframe. This effort consisted of 
several different programs — one of them, a user 
application under CEO, directed the mail to what 














we called a mail sender. This software process ran 
on the DG machine and used DIA to send the mail 
over to the IBM. Another piece of software would 
poll the IBM and ask if there was any mail for 
anybody on the DG system, then bring the mail down, 
format it, and send it through the CEO network to 
the end-user's inbox. In a sense this was a prototype 
for what we would do later. 


In phase two, announced more recently, we set up 
a more sophisticated mail protocol, SNA/DS. And 
users can file and retrieve documents on the IBM 
host, just as they can in public drawers on a DG 
system. Instead of having to be directly connected 
to an IBM host, they can be connected to a System 
36, a System 38 or an IBM 5520, which is a shared- 
logic office automation system. That's where the LU6.2 
capabilities came in. 


Communications seem to be largely about stan- 
dards — is that also true for communications with 
IBM equipment? 





When you talk about ISO and other industry stand- 
ards, people always go to a bunch of manuals and 
papers that delineate what's supposed to happen in 
the various layers of the ISO model. IBM does the 
same thing for their SNA architecture. But as I said 
earlier, if you're trying to build an interface, you 
really want to work on the product itself. Our interface 
has to work in practice, not just in theory. So, the 
definitive answer is in the final product. 





What else is different about IBM communications? 


IBM's philosophical approach says that your network 
and your computer system should be hierarchically 
organized. Because of the way these systems evolve 
in a customer environment they contain all the ac- 


counting records — the most important data. And 
the data grows to a point where it's worth hundreds 
of millions of dollars a year in a continual investment 
to maintain and manipulate that database. Because 
it's so important to their business, customers are 
nervous about doing anything that might rock the 
boat — they're concerned about security and relia- 
bility of the software they're using. They put in very 
tight controls and have very large networks — they 
run what we call a closed shop. They're nervous 
about people coming in and touching their system, 
and they're not amenable to tweaking or changing 
things. 


In a minicomputer environment there’s a lot of 
timesharing — people write their own programs and 
exercise much more freedom. The software isn't nearly 
as complex because it wasn't trying to support 10,000 





terminals all around the country — only hundreds 
in one building. The architectures are different, what 
you're managing is different, and the mental proc- 
esses and concerns are different too. If the IBM 
mainframe goes down, people can't book orders — 
customers get very concerned about that. It's a phil- 
osophical difference of tighter control, hierarchical 
approach, and very large computer systems’ net- 
works. 


And that would mean a very different approach to 
the computer from the system management point of 
view ... 


Yes. If you were to install an IBM mainframe and a 
set of software to handle 100 terminals, it would 
require a lot more work than to install a DG system 
that supports the equivalent load. But if you have 
tens of thousands of terminals, there’s currently no 
systematic way to even begin to approach the prob- 
lem in the DG environment. In the IBM environment, 
on the other hand, there is a systematic way of doing 
it — but it requires layers and layers of system 
programmers, managers, and so on. They have to 
work very closely together or it won't work at all. 


So they have to follow very rigid rules ... 


Yes — very rigid rules to keep control so they don't 
trip over each other. 
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And if you're trying to develop an interface for your 
product to an IBM product you're confronted with 
that same set of rules? 


Yes, for instance within DXA we have to coordinate 
the installation of the product with at least three or 
four different system programmers on the IBM side, 
each responsible for a different layer of the software. 
And all these people have to sit down together and 
agree on certain aims, parameters, and uses of var- 
ious features. From a DG customer's point of view, 
he has to convene a group of people he’s probably 
never seen before, or even knew existed in the com- 
pany, and he has to understand the IBM terminology 
as well as ensure that someone on the DG side 
knows it too. So part of our job as a company is to 
help that customer relate to the issues and complex- 
ities on the IBM side. It's not unusual to get those 
groups together and have it take two to three weeks 
for them to actually implement decisions. Although 
it only takes an hour to change the software, those 
changes are very carefully controlled and scheduled 
on a weekly, biweekly, monthly basis. It's not like 
dropping a software tape on an AOS/VS system 
where it’s up and running the next day — there are 
too many complications. 


How does DG's product line compare with other 
companies’ IBM interconnect? 


Right now our office system interconnect to DISOSS 
is the most sophisticated in the marketplace. We have 
SNA Distribution Services [SNADS] support — no one 
else currently has that. Consultants praise us for the 
level of integration we currently have with CEO, and 
for our library services menu interface. 
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You started with nothing, used the first phase to 
train people, and then applied that experience 
through the second phase. You must have a pretty 
confident group of people. 


An extremely competent set of people — they're 
amazing. I don't think even they understand the 
extent of all they've learned in the last year. Most 
IBM system programmers go to school for six months 
and practice for two years before they can do what 
some of my guys can do now. Given the level of 
understanding they now have of the IBM environ- 
ment, there's probably not much they couldn't tackle. 
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THE NEW EXECUTIVE 


In the old days, software design was limited by the 64kB addressing capabilities of Data General's 16-bit ECLIPSE 
machines. To get around that limit, the operating system [AOS] was designed as several distinct components, one of 
them known as EXEC. The EXEC component was nothing if not eclectic — it managed a multiuser environment, logging 
users on and creating their initial process; its batch function handled noninteractive jobs; its cooperative function took 
care of spooled jobs like printing; and its mount function supervised the loading of data to and from magnetic tape. 
Years later EXEC was engineered into AOS/VS to run on the company’s first MV/. Joined to the 32-bit world, where 
64kB addressing was no longer a constraint, the dotted line of its ancestry nevertheless remained. 


Finally a group of /VS designers decided it was about time for history — that is, EXEC — to be rewritten. What is 
unusual about their project isn't so much the component or the technology, but the fact that they'd been pursuing it, 
through stops and starts, over a period of two years. By August the new EXEC had reached SQA with the group still 
intact. As the designers tell it, this project succeeded largely on their mutual interest in making a better product. 





Taking the hurdles 





"There were several good reasons to rewrite EXEC, one being to 
expand the capabilities of the 16-bit version. We were knocking up 
against the hard limits of the number of users who could be logged 
on, the number of printers that could be supported, the number of 
queues that could be created, the number of batch queues. Customers 
needed those kinds of increases, and we knew Data General would 
need them too. We could see bigger machines coming down the road 
that would support greater numbers of peripherals and terminals; 
eventually our software would have to support them too.” 


"Most portions of /VS were a transliteration of 16-bit AOS, and the 
people who did that transliteration thought they were looking very far 
into the future in terms of supporting customer needs and the size of 
installations. But today, in EXEC and almost every other facet of the 
operating system we've come up against the numerical limitations they 
imposed. We're even running out of error codes that we can dish out 
to other projects.” 


"There were also goals in terms of ease of use: the ability for programs 
like the SMI, which has a friendly interface, to access functions in 
EXEC, which itself isn't so easy to use. In fact, the reasons for a new 
EXEC were undeniable. It's just that they weren't driven by an im- 
mediate hardware need, and those kinds of projects are a lot easier 
to justify and staff. In the end we rather craftily made ourselves 
absolutely necessary for Devios [AOS/DVS]; you could not ship the 
operating system without the new EXEC. But for a long time we were 
pressured to fold everything Devios needed into EXEC/16. Then, EXEC 
being lord of the operating system so to speak — the overseer of what 
goes on for timesharing — so many things would come up. There was 
support for the old EXEC and new things going on in /VS, and they 
just threw all schedules off completely. Morale took a turn every time 
one of these things came along. And while we were psyched for the 
challenge, we kept wondering, ‘Are we going to be able to keep this 
ideal situation going for very long?’” 


"Somehow we managed to keep that group together for a year-and- 
a-half, maybe two years, of solid development work. The project leader 
was there saying the right thing, and also insulating us. We got the 
isolation that allowed us to finish EXEC and produce a product we're 
proud of.” 








Making It Better 





“If you look at the code, you'll find a much better separation of functions. 
The old EXEC product could have as many as four tasks executing 
through a single piece of a module with poor control over who was 
modifying what, especially since all of the code was unshared, and 
therefore unprotected, and often had storage mixed in with the code. 
When you're talking about something that’s multitasked, that's a real 
problem. The new EXEC has a message-passing design that eliminates 
intertask collision problems. It's better code.” 


"I did a lot of work early on in the logon world, which provided a 
foundation for the rest of the group. Here we had the first piece of 
the new product in place, ready for others to integrate into, and | set 
up a demo so you could see that it worked. That pushed people along 
quite a bit I think, because at that stage the project was just starting 
to come together and things were still slow. So this was a real motivating 
force.” 


“Some of the highlights in the queue world are that we now have 
programmatic access to queue display information, and we've added 
the modify commands. | think those are a big win.” 


"In the old version, EXEC commands could only be accessed by an 
operator through the CLI. Now that we have ?OPEX [the new system 
call interface], we also have a programmatic interface to EXEC func- 
tions. I think customers are going to be very excited about that. The 
SMI project has already made good use of ?OPEX, and there are 
people out in the field who will definitely use it to their advantage.” 
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“The batch/coop world allows the processing of batch processes, with 
greatly increased limits and many active jobs. We started with a state 
machine, which had been implemented, and enhanced it. [A state 
machine tests an input and decides what code path to take.] The batch 
and coop worlds fit into that very nicely because both processes flow 
in a well-defined sequence.” 





“A user accustomed to the old mount world won't see any major 
difference, rather it's intended that he won't. But in the design area 
it's quite a bit different. Data structures are organized to allow for 
better efficiency and reliability. Status bits have one and only one 
meaning. Debugging couldn't have been easier. All of this is trans- 
parent to the user. I also tried to promote a model of the [human] 
operator as a device from the design point of view ... to lay the 
groundwork so that in the future, should this notion of distribution grow 
a little bit, we have a way of describing a number of operators to 
EXEC, each of whom could service mount queues on other systems. 
So the design is extensible.” 


"T'm really amazed at how compatible it is. There was no functional 
spec alive that could've listed all the nuances of what EXEC did, so 
we had to go back into the old code to get that one-to-one corre- 
spondence in functionality. When it came down to it you'd find people 
reading through the 16-bit code and translating it to 32-bits.” 





“It's definitely a better product than before. You don't lose IPCs, you 
don't lose commands, you don't lose messages you send to EXEC. It's 
modular, it's more reliable, and the design doesn't impose any nu- 
merical limits — we imposed them just to be realistic.” 


“The model is so flexible that you can begin to consider directions 
you would never think of with the old EXEC — whether it makes sense 
to extend the same world to multiple systems, or even whether the 
queue and mount worlds should live on different machines. There will 
probably be requests for enhancements, and it will be easier to make 
them. I think we've really planned for the future MV/100,000s out 
there.” 





In Quality Assurance 


“EXEC is so large and has so much functionality that you really have 
to pursue two different slants of the quality issue. One is, do the things 
that everybody's going to use really work? The other more interesting 
part is, what are its limits and weak spots? Just as the developer is 
putting together his piece and thinking, ‘How can | build up a defense 
against the malicious user?,’ I take on the role of the malicious user 
and see if there's something I can break. | try to assume the mindset 
of what I like to call the ‘psychotic operator’ — a person who sits 
down and starts typing whatever comes into his head. Maybe he’s 
learning to use the system, maybe he’s just goofing off. Of course, if 
the objective was only to find problems, you could hire a zoo of monkeys 
to beat away at it until they hit an error. But if your objective is to 
fix problems, then you have to figure out in detail where they are and 
what causes them.” 


“Quality assurance is still very much a child science. A lot of different 
hunches and indicators come into it, but through experience and in 
talking to different people you learn which ones to trust. One of the 
first things to look for when you have a very interdependent product 
like EXEC is the communication points. Look for the points where EXEC 
has to communicate with the agent, the CLI, the operating system: 
that's usually where all the weak spots are. And then, EXEC itself 
being so large, look for communications within it. One of the first 
things I found was that while the EXEC designers had coded 1,024 
jobs in a queue — immaculately, with no errors — there'd been a 
lack of communication with the CLI, which wasn't ready for more than 
1,000. That was a simple thing to fix once I showed them.” 


“At first I found one problem after another, but because the EXEC 
group has been so cooperative, I'd go down there with a report and 
usually, in a day or two, they'd already have it fixed. And I don't 
remember seeing any problems that recurred after they were fixed. 
That's incredible. I mean, problems a/ways recur; that's why we keep 
running things. This time the reason we were running tests was that 
one problem might lead to a further problem underneath it. To have 
such a fast turnaround was a refreshing experience. Each new version 
of the product was better than the one before. We could see it improving 
on a daily basis.” 





And Finally, Software Release 


“IT dreamt about it. I'd go home with a problem that I'd been working 
on and I'd end up dreaming about it. And sometimes I'd wake up 
thinking of the potential solutions.” 


“T look at it and wonder how we got through that much time with a 
stable staff and such a drive to finish it. 1 know how the others felt; 
there were a lot of ups and downs. But between us we had a tremendous 
commitment, I mean a real desire to finish the damned thing. And 
you know, that drive was probably what kept it going.” 


“It's a good product now. And it runs. I mean, it's a joy to see the 
thing up and running.” 


“When you put that many good people together you come up with 
the right idea, the right solution. You'd go into a meeting and sometimes 
you'd come out turned right around because you were convinced that 
this is the right way — this is the way design teams are supposed to 
work.” 
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THE ONCE AND FUTURE CEO 


If there is one product at Data General that is the most visible; the most widely used and abused; the most taken for 


granted when it works; and the most missed when it doesn't — it is CEO. In September, over 5300 customers had 
installed this office automation software in their businesses. Data General itself had the largest CEO network in the 
world. The product was in its fifth year of incremental enhancements. And the developers were about to release another 
major revision, this one integrating a voice mail capability. 





EVOLUTION, NOT REVOLUTION 


Viewed from today, it is hard to imagine that CEO was once a small collection of components, limited 
to a single system by relatively primitive network underpinnings. Its growth, and its success, were 
evolutionary rather than revolutionary. In the following interview the manager of Office Automation within 
the CEO development group gave us a sense of how the larger CEO product has taken shape from a 
series of short- and long-term enhancements. 


CEO encompasses so many components ... how is 
its development organized? 


There are several groups that develop CEO, and 
many others touch it in some way or another. My 
group develops the CEO core product, the file system 
and basic components like E-mail, calendaring and 
printing. Working closely with us are the Word Proc- 
essing, Decision Base and Graphics groups. CEO 
Connection responsibility is in RTP, and the document 
exchange product, which interfaces with IBM's ar- 
chitecture, is done in the communications group. 


Looking across all of these groups, what have been 
some of the major areas of enhancement? 


Of course rev 2.20, with the voice messaging ca- 
pability. This is the only voice system that's really 
integrated into an OA product, and it represents a 
major piece of work. There are other, stand-alone 
systems with a few more functions than ours because 
we currently lack a PBX voice interface — that will 
come; but we feel the integration with other OA 
functions will be most important in this and other 
voice applications. 





Rev 2.20 also took us a few steps further as far as 
integrating user applications into CEO. Initially we 
developed the AUI [Agent User Interface], which 
allows a program written under AOS/VS to com- 
municate with CEO — to read an inbox, send a 





message to a CEO user, or access the filing system 
from another program. 


The next step was someting called CEO Toolkit. It 
incorporates the AUI but also provides a library of 
routines, such that an application running in con- 
junction with CEO can maintain a CEO status line, 
use the CEO calculator, use the Interrupt key and 
access the filing system. Now third-party developers 
can build products that run as what we call ‘inte- 
grated applications’ directly under CEO. In fact, we're 
using the Toolkit ourselves to develop the ancillary 
CEO products — the spreadsheet, Wordview and so 
forth. 


This is an important transition for CEO: where orig- 
inally it was developed and perceived as an appli- 
cation, it's now becoming an applications platform. 
You'll see us continuing in that direction until, from 
a programming point of view, CEO can almost be 
seen as your operating system in the sense of offering 
increasing facilities for user applications. 


RTP has done more work to accommodate non-DG 
applications with CEO Connection. The initial product 
let you build CEOWrite documents on a PC and 
transfer them to the host, and each incremental en- 
hancement has added more functionality and trans- 
parency to that linkage. Over time, the idea is to 
distribute pieces of the application directly onto the 
PC; to have a workstation run your PC applications 
while serving as your gateway to CEO in the most 
integrated way possible. 
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What about other enhancements not necessarily fea- 
tured in this revision? 


There are some major developments that are less 
visible today than they will be in the future; one of 
these is distribution. Our work in this area stems from 
the fact that when CEO was designed, no one really 
foresaw how successful it would be in terms of the 
need to support large organizations. It was essentially 
a stand-alone product that would run on a small AOS 
or AOS/VS system — remember, the top-of-the-line 
back then was the MV/8000, an order of magnitude 
less powerful than today's MV/20000. Even the ability 
to send a piece of mail from one system to another 
was limited, because we didn't yet have network 
routing. So I don't believe that the huge number of 
networked systems we have today was at all fore- 
seen. 





As soon as the networking people implemented a 
routing capability, CEO spread like wildfire through 
Data General. Where before there had been little 
pockets of CEO within the company, in a very short 
time there was a whole corporate network including 
sales and field offices; and of course, the product 
was catching on in the marketplace as well. 


That just opened up a whole new range of needs in 
terms of how to manage this vast network as one 
common user community. Today's CEO has some of 
the transparent distribution capabilities needed to do 
this: for instance, the ability to print on printers con- 
nected to another host or schedule meetings with 
users on other systems. 
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What about more incremental enhancements ... im- 
provements that may appear less significant by 
themselves than when viewed in the aggregate? 


There are many of those. One that's worth mentioning 
is the international aspect of CEO. I think CEO has 
been a trail-blazer for DG in building a truly inter- 
national product. Just what that means has unfolded 
slowly over time as we discover more and more 
requirements for internationalization. 


At first, it was most obvious that we had to translate 
the menus and documentation, so that when a Span- 
ish user comes up in CEO he sees menus, error 
messages and Help files in his language. That work 
is done in a group called International Software and 
Documentation, with other initiatives taken by local 
offices or distributors in Europe. 





But translation is only one aspect of the internation- 
alization of a product. Another one is character sets, 
so I can type characters like a pound sign or any 
of the commonly accented characters used in the 
European languages. We have an international char- 
acter set, DGI, for that purpose, which is implemented 
in a soft key, along with different keyboards for each 
country with the appropriate characters already on 
them. 


But even that doesn't take into account some of the 
finer points like data formats, currency symbols, the 
use of commas and decimal points which is different 
in Europe, and rules of spelling and hyphenation 
which are different in every language. Even the 
paper size is different — about a half-inch longer 
and narrower than in the States — and every country 
has a different standard for punching holes in paper! 
When you think about it, CEO is a language-based 
product, and the issues of accommodating a multi- 
national user community are as complex as language 
itself. 





Beyond that, there are a number of standards emerg- 
ing in Europe for communications, the most recent 
being X400. This protocol defines what a message 
needs to look like in terms of its data structures. For 
instance, when we built CEO five years ago we made 
certain decisions about our data structures — ‘Well, 
we'll put the text here and the Confidential bit here 
and the Certified bit there.’ And when DEC or Wang 
designed their messages, they made their own de- 
cisions too. So while we can't send a CEO message 
to an All-In-One system, with X400 we can send it 
to any other system using the same standard. 





With such a large installed base and so many dif- 
ferent components, how do you define what goes 
into each CEO enhancement? 


Differently than we used to. (laughs) Some time ago 
our direction changed with the realization that we 
could no longer concentrate all our resources on 
enhancement, enhancement, enhancement as each 
request came in from the field. These enhancements 
were largely one-offs based on the loudest customer 
or the loudest sales rep, and we found ourselves 
spread too thin in development to the detriment of 
performance and reliability. 





Performance and reliability have to come first, be- 
cause satisfying the demand for a given feature will 
only create more noise if the feature doesn't perform 
reliably or well. We've done quite a bit of work in 
this area, including converting the entire product from 
16- to 32-bits. This is allowing us to do a much better 
job of tuning performance characteristics. We've also 
become much more rigorous in dealing with STRs. 
It's an imperative — CEO has gone from an inter- 
esting curiosity to a product that whole organizations 
absolutely, positively depend on. DG is a perfect 
example of that. 


How do you balance that, the demand from the field 
with the longer-term interests of the product? 


It's very difficult to say no when someone says you've 
got to have this feature. In the past we'd try to squeeze 
it in, until all our time was scheduled for enhance- 
ments with very little left over for regression testing, 
feature testing, performance testing and so on. Until, 
under pressure to get enhancements into the field, 
we put out a rev that wasn't ready to go. That made 
it very easy for us, from then on, to take the time. 
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It isn't that the rev was bad, but that it wasn't fully 
debugged. And in the end it created more work in 
development to fix it after the fact than if we'd spent 
the extra time in the first place. In the long run, that 
kind of pressure can make the product later rather 
than earlier. I think marketing and the field now 
appreciate with us the need to approach enhance- 
ments more systematically, and our whole process 
is greatly improved. 


To get back to your initial question, the way we 
determine enhancements ... There are two parts: first, 
assembling the long list of candidate enhancements, 
which come from several sources. The most direct 
source is the STR process. In addition to submitting 
bugs or problems, customers send us suggestions 
ranging from ‘Why don't you make these two menus 
consistent’ or ‘This word is spelled wrong’ to ‘Why 
don't you add voice annotation of documents.’ 





We've also established ties with OASIS, an OA spe- 
cial interest group of the DG Users Group. We par- 
ticipate in their meetings and workshops as guests 
and speakers, but it's also an excellent forum for us 
to find out what the real needs are down in the 
trenches. 


A great deal of input comes from Product Marketing, 
of course, which gets its input from the field, from 
consultants, from analyzing competitive products and 
from looking at RFPs [Requests For Proposal]. To- 
gether, these sources generate enough ideas to keep 
10 Data Generals busy. 


From that we have to select based on short- and 
long-term interests. We meet regularly with Product 
Marketing not only to make these decisions but to 
review them in real time, so we can fine-tune them 
or change them as appropriate. It's a picture of the 
product's direction two or three revs out, but it's a 
living, dynamic picture. 





I think we've finally arrived at the optimal decision 
making process. It's balanced, it’s systematic, and it 
allows us to be both proactive and reactive, which 
is appropriate for where CEO and Data General are 
today. I'm very happy with it ... 1 think we have the 
best relationship between a product development 
group and marketing in this company. 











REFLECTIONS ON THE FUTURE 





Serendipity may have had a hand in making CEO the industry's flagship office automation product. But only far- 
sighted planning and strategic thinking will enable it to maintain its leadership position. With CEO approaching its 
fifth anniversary, it seemed logical to ask what's in store for the product in the years ahead. We asked the Director 
of User Systems, to give us a glimpse of the future — not of individual features or enhancements, but of the larger 
technological and marketplace trends that CEO will respond to. 


"I can remember the days before CEO, when we had various sets of 
text editors that we used to enter and print documents. They went under 
the names of things like TUBE, which was replaced by AZTEXT — early 
word processors that were perhaps an attempt to compete with Wang 
and other stand-alone word processors in vogue at the time. 


“Wang's was the quintessential product of that kind — simply a stand- 
alone machine with built-in functionality and nothing else. With the first 
release of CEO, I think its major characteristic — the thing that appealed 
to me and to the customer base — was that we had an integrated set 
of applications. And while none of these were outstanding at the time 
of the original introduction, the synergism of having total and complete 
integration, with a unified system interface, made the product better than 
the sum of its parts. From the earliest days people may have felt that 
the CEO word processor lacked function A or B. But people still bought 
CEO word processing because you could create a document, you could 
file that document in the filing system, you could come back and edit 
it or duplicate it and perform other office functions, all with a very easy- 
to-use menu interface. 


“Since then that integrated set of applications has been enormously 
expanded and improved, until we have a CEO product today whose 
functionality goes far, far beyond that of revision 1. Looking ahead three 
years from now, the CEO of the future will change through incremental 
enhancements just as dramatically. I can think of four or five trends, 
just for starters, that CEO will need to accommodate in either the near- 
or the long-term. 


"The first is document processing. Word processors were and are es- 
sentially text processing programs that allow some amount of flexibility 
and an interface to a printing subsystem. The future, especially with the 
advent of inexpensive printers, is moving absolutely to a WYSIWYG 
capability — what you see is what you get — where the user can format 
documents into many alternative styles with different character sets, 
different font choices, different page layouts; and then instantly go to 
masters for reproduction, providing manuals or other materials at a 
fraction of the cost of the conventional printing cycle. 


"The second trend is in document exchange. Today we recognize and 
coexist with IBM. But the OA system of the future is going to have to 
understand and accommodate electronic document interchange not only 
between DG and IBM systems, but between DG and all other manu- 
facturers. That means performing the code conversions and other func- 
tions necessary to put documents in editable format across dissimilar 
networks, so they can be operated on by systems that we're not even 
aware of today. Standards in this area are just beginning to emerge 


but are still murky; in the three-year time-frame I believe they'll become 
stable enough to integrate in our product. 


“In the area of voice, CEO already supports voice messaging and will 
soon be able to read an inbox to someone who calls in over a touch- 
tone telephone. But the real promise of voice isn't voice messaging or 
calling in to have messages read. It's the total integration of voice into 
the system — being able to voice-annotate any object, whether it's a 
memo, a spreadsheet or a graph; and being able to mail this document 
with the annotated voice around the network, passing the verbal infor- 
mation directly on to the recipient. 


“Along with that, a few companies in the U.S. have done considerable 
research into going from pure speech to text. Those systems are oper- 
ational now with small vocabularies. Over the next few years they'll be 
extended to vocabularies large enough to support meaningful text ap- 
plications, where you can talk into a phone connected to your terminal 
and receive the full text. That text can then be edited in the word 
processor, voice-annoted if necessary, and mailed across the net- 
work — this is almost starting to happen today. 


"In the decision support area, CEO started out with a spreadsheet, 
enhanced the spreadsheet with data tables, and then made numerous 
enhancements to both. Rev 3 of CEO Decision Base added graphics 
with an easy-to-use interface that let users produce color charts from a 
number of sources, integrate them in documents, and mail them over 
the net. From there it's easy to envision more extensions along these 
lines: things like being able to collect data from a variety of dissimilar 
sources — a spreadsheet on one machine or a data table on another; 
to build a chart from that data and incorporate the chart into text. 


“And finally, the CEO of the future will need to support non-DG-written 
applications. There is no way we can provide applications competing 
with every two-person garage that's turning out software in the U.S. But 
we can provide a platform to run those applications in a manner 
transparent to the user. And with a small subset, we can provide a tight 
coupling between the application and our system. Along with that, there 
is a trend away from the non-intelligent terminal mode of today and 
more toward putting the compute power on the desk, where its directly 
available to each user. So there is a convergence of hardware & software 
trends, and it will lead, I believe, to an open architecture based on high- 
powered workstations connected to server machines over networks. 


“CEO will undergo a very significant transformation as it responds to 
these trends. And yet, its extraordinary value will continue to be that 
synergy of functions. The applications and topologies will look very 
different, but CEO will continue to be the unifying platform for them.” 


A YEAR IN DEVELOPMENT 
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THE USERS HAVE THEIR SAY 


After talking with someone who designs CEO, we thought it would be interesting to hear from some people who use it. The 
following are excerpts from interviews with a random selection of Data General employees who were asked to comment on their 
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experience as CEO users. 





Brian is an ECO coordinator who works in the Information 
Management Department. He's been at DG for 8 1/2 years. 





"CEO had been in the field for about a year before we got it. Learning was a 
little discouraging at first because we didn't have the equipment. And it was 
limited because not that many other people had it, so at first CEO was a bit of 
a toy. But once we got the equipment and got hitched up to other users, well, 
now you couldn't take it away from me. 


“If I'm here 8 hours a day, it's on 8 1/2 hours. I use the mail, I use data tables, 
I use the speadsheet, I use CEO drawing board; I'm taking a course next week 
on CEO graphics. All the specs we get in the print room are handled through 
CEO. We can go over the network and pick up MRP, which is for materials 
planning, and we can pick up BOM2. As of February we will no longer be 
sending ECOs out on paper; we'll be distributing everything over CEO on a 
worldwide basis. There's really not much we can't do, except when it’s down. 
(laughs) 


"I've been replacing a lot of the phone work with CEO. If I send it on CEO I 
know when someone's got the message. And calling Mexico or Colorado gets 
expensive, so I'll do it on CEO. I can get messages to the Far East quickly, and 
if I get in early enough I can catch someone in Japan working late and we'll 
go back and forth. In any case my message is waiting there when the person 
comes in, and | know that they saw it so they can't ignore me — only if they 
see my name, then they don't have to read it (laughs). 


“When the system's down it's like, what do we do? All our records, all the 
electronic documents in the print room are stored in CEO; all our ECOs will be 
on CEO; the ability to hitch up to other systems, the BOM2, MRP — all depend 
on it. When CEO is down, we're down. There's only one thing | continue to do 
on paper: those spreadsheets. And when CEO goes down I'm able to catch up 
on them. Other than that, I log on before I take my coat off.” 





Violet works in Manutacturing Financial Planning and has 
been with the company for two years. 





"I started using CEO my first day here. It was real easy to learn. I mean, ‘user 
friendly’ doesn't even describe it, with all the Help keys. You don't even need 
the manual. You can just muddle your way through the system and learn how 
to use it. Plain English. 


“We use just about everything on it. We transport information between manu- 
facturing facilities through CEO Mail, we integrate other types of files through 
CEO for presentation purposes, we have a lot of word processing and a lot of 
financial applications like Decision Base — it's our link to all the other applications 
that we've developed for this department. In fact we have to log on to CEO to 
get to other applications. If I want to use EPS or Trendview or anything that 
they've automated, I go through CEO. They hook everything and its mother up 
to it.” 





Jonathon, a senior producer in the Media Services Department, 
creates slide shows and sound tracks for clients throughout 
DG. He's been with the company for two years. 





"I started using CEO straight away, as soon as I got here. It was very easy, 
very self-explanatory. I use it every day, mainly for electronic mail and to write 
scripts for the slide shows and sound tracks that we do. 


"A lot of times CEO will be my first contact with people. But then I need to sit 
down with them live and in person as soon as possible. The limitations of CEO 
come in when you actually want to reach someone's brain personally. When | 
need to come on myself, that's where CEO ends and where real contact needs 
to come into play. 


“In terms of the word processing, it does tend to change the way I write. It's 
very different writing on a terminal than on paper; it can change the content 
and it can change your approach. | find that I write more quickly on CEO; but 
when it comes to reviewing a document, it takes much longer if I’m doing it on- 
line. You do need to print it out to see the whole thing together. I’m not sure 
even windows would change that. 


"Do I communicate differently over CEO? No, I don't. Live in person, CEO, over 
the phone, handing a note to a small dog to carry to someone — it's the same 
emotional quality. And I think we all know what that means. (laughs) I'll be 
serious about it ... Sometimes I'll just blast off a message: Dear Patti 1) Your stuff 
is ready, 2) come down and get it, and 3) the game's cancelled tonight. If I called 
up I would shmooze a little more, talk a little more. But if I don't feel in the mood 
for that or I don't have time, I can blast off a real business-like kind of thing. 


"I can also do things uniquely with CEO that I couldn't do otherwise. I have a 
quote-of-the-day network where I send out some kind of wry, pithy, vulgar, 
humorous ... who knows what it is from day to day. It goes out to maybe 50 
people, and of those 50 some 15 of them send it to yet another 50 people, who 
then send it out further. Although it's not directly work-related, in some ways it 
keeps myself and Media Services in people's minds and offers us visibility. A lot 
of people who need our services may not know that we exist. So if I do it every 
day for a year and from that two or three people bring us work, well, there you 
have it. And it's happened. | think it’s a good use of CEO." 
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Nancy works in Corporate Typesetting Services and has been 
with DG for 14 years. 


“We didn't have CEO on our system until quite a while after it was introduced. 
I haven't had any courses; I learned mostly on my own, asking a few questions. 
I don't use it deeply, but what I do use I like a lot. 


"Rather than type every job, a lot of customers will give us work in CEO. It 
saves a lot of duplicated effort — them typing it, us typing it, and then coding 
it. In the past people would give me documents on mag tape, so I'd have to get 
the tape, walk down the hall to the lab and dump it onto our system; sometimes 
the tapes were bad, sometimes the files weren't loaded right ... it was a hassle. 
I'd say approximately 70 percent of our work is now coming through CEO, and 
we've almost completely done away with mag tape. We're now even accepting 
work from the Educational Services group. They're sending me Penta-coded files 
via CEO, I'm processing them through the Penta system and bit blasting them 
or typesetting them. It's made life a lot easier for them as well as us.” 





Dot is a secretary to the Director of Business 
Planning in the Communications Systems Group. She's been 
with the company for five years. 


"Il was here when they first started using CEO. It brought confusion; organized 
confusion in the beginning. I remember going over to 2400 and taking a course 
in it, and we all sat there like we had three heads. The gal who was teaching 
it, she was new to it too, and she'd tell us, ‘Well, you'll, you'll learn this, you'll 
learn it.’ But we just sat there like ... (rolls her eyes and laughs). Other than that, 
you learn as you need to use CEO — that’s what I've found. I'd pick up the 
manual and read about different commands and so forth, but unti] I had to use 
them myself, they didn't mean anything to me. ‘Wastebasket’ to me was just 
something on the floor, but now I realize what that function is and what it does. 
So I've adjusted to it. In fact, I couldn't see a day without it. 


“Now that my boss is in this new organization, I contact a lot of people outside 
Westboro: the sales reps at our New York City office, the Sunnyvale Division, 
the Genioss people in Texas, I talk to them. What I find is that CEO is a telephone 
for me, it eliminates the telephone. I think people read their URGENT messages, 
whereas they could hear the phone ring twice and know it’s an outside call and 
say, “Oh, | won't answer it.” With an URGENT message, I think it's the curiosity 
factor that gets to people. Scares them. But I'm very careful using URGENT. I 
don't abuse it.” 











Gary is a writer of employee communications in the Public 
Affairs Department. He's been with DG for two years. 


“CEO was fairly easy for me. I never took a class in it, but it kind of walks you 
through things with the menus and Help key, so it didn’t take long for me to get 


up to speed. 


"T use it constantly. My main responsibilities here are producing Interface and 
doing News On-Line. Both of those are really dependent on CEO, particularly 
News On-Line because we produce it right on the system. It contains important 
DG news and short clips about the industry from the dailies or the trade press. 
I write up some of it, some of the other people in the department write up their 
input and send it to me, and I integrate it all and send it out from my terminal. 


“We used to maintain our own mailing list of about 600 people, individuals mostly, 
but it became very cumbersome. The formation of IMG, the Information Man- 
agement Group, saw the opportunity to allow each system manager to maintain 
their own list of the users on that system, which I assume they do anyway. So 
I can send out to one name per system, and it will get zapped to the hundreds 
of users on that system. Eventually, say there are 600 systems in the company, 
I would just have 600 names. And everyone with a CEO terminal would get 
News On-Line. That's a little ways off now, but we're moving in that direction. 


“With Interface 1 do all my articles on CEO. I use it for a lot of my approval 
process instead of sending hard copies out for review, especially if it's not in 
Westboro. Depending on where I am in the production cycle there may not be 
time to send hard copies back and forth. If I need it the next morning I'll send 
it over CEO and get a response when the ‘URGENT’ flashes on my screen. That's 
kind of intimidating sometimes (laughs), especially at 4:30 on a Friday. 


"If CEO were to disappear tomorrow it would make life a lot more difficult. It 
would make Interface a yearly publication instead of what it is now." 


A YEAR IN DEVELOPMENT 
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REMOTE 
POSSIBILITIES 





In the engineering lab opposite the Viking debug station, another Viking processor was nearing completion. The DRP, 
short for De Real Processor (or, grudgingly, Diagnostic Remote Processor) had long ago exceeded the normal diagnostic 
functions it was supposed to handle — as well as the PROM space allotted to handle them in — and had become a 
jack of several trades to the Viking system. As two key contributors remember, the space ran out before the possibilities 
did, so the designers just sort of invented it. Here they explain the different functions of the DRP and how it evolved. 





What is the DRP? 


Danny (diagnostic software designer): It's a small 
computer system dedicated to diagnostic functions 
on Viking. We implemented it on the memory and 
I/O controller board using the same microECLIPSE 
microprocessor that's in our DESKTOP GENERATION 
Model 20. 


The DRP performs a lot of functions ... It manages 
system powerup and initialization, it monitors the 
powerup diagnostics, and it implements the system 
control program [SCP] which allows the operator to 
troubleshoot programs by stepping through them and 
examining specific memory locations. 


The DRP also interfaces with the system console 
terminal, the front panel, and the new power supply 
controller [PSC]. We built in a remote diagnostics 
capability so our field engineers can diagnose hard- 
ware and software problems from their office. Let's 
see ... We also log system errors in the DRP — those 
provide troubleshooting information; and we supply 
the system clock — all the other clocks are derived 
from that. 


How does the DRP compare with the diagnostics 
system on the MV/10000? 


Bob (senior diagnostic engineer): More function in 
less board space is the big win throughout the Viking 
design, including diagnostics. Just as the Viking CPU 
is on one board while the MV/10000 is many more, 
the SCP takes up a quarter of a board on Viking 
where it used to have its own board on the MV/10. 
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We also added a diagnostic bus called the RNB 
[remote network bus], sort of a back door that lets 
us talk to controllers without getting in the way of 
the operating system. The RNB is extremely simple, 
eliminating the entire 15-inch power supply controller 
card that you find in an MV/10, yet it can be used 
for a level of diagnostic status we've never had 
before. 


Danny: With the MV/10 it was possible for a field 
engineer to get remote access to the diagnostics, but 
only by attaching an expensive commswitch box to 
the computer. The box was a little bigger than your 
tape recorder there, and cost upwards of $1000. We 
took that commswitch function and integrated it into 
the DRP, eliminating the cost completely. And our 
solution is also capable of calling out to Field Service, 
not just letting them call in. 





I understand that the initial diagnostic plan called 
for a Z80 processor instead of the microECLIPSE. 
Why the change? 


Bob: The Viking CPU was mostly designed before 
we came on board, so there wasn't much space left 
for diagnostics. The hardware team had specified 
the Z80 because it lets you put together a minimal 
system with just a few parts that you can buy and 
hook together easily. We wanted to use a micro- 
ECLIPSE for several reasons. First, it has a lot more 
functions built into it than the Z80, which is more of 
a toy processor. Second, we have a lot of ECLIPSE 
programmers here at DG, but very few Z80 pro- 
grammers. And third, we have a lot of programs 
already written for the micro—ECLIPSE because we 
use that product. Also, this being the peak of the 
development, the microECLIPSE let us borrow people 
from other projects, like Mark Crooker and Jim Petrie, 
and bring them up to speed within hours as opposed 
to weeks. 
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We wanted to take advantage of these savings, but 
first we had to overcome the perception that it would 
be too expensive in real estate. Because in the past 
the microECLIPSE had only been used in major pro- 
cessors like the DESKTOP GENERATION and the 
ECLIPSE $/120, people suspected that it would take 
a prohibitive number of chips to hook up to it. So on 
a Friday I convinced management to hold a feasi- 
bility study. The review was scheduled for Monday. 
And that weekend the DRP got designed. In the study 
we were able to show only a 10 to 20 percent greater 
usage of chips than the Z80, which was very 
good — people had assumed it would take two or 
three times as much. 


So you had very little space to begin with. How did 
that affect the way you designed? 


Danny: Our initial goals were to improve the features 
of the MV/10000 and to support more than one pro- 
cessor. Besides that, we needed to provide a bus 
interface — the RNB — to communicate with the 
new power supply controller, and we wanted to re- 
place the add-on commswitch box with a direct con- 
nection. 


Originally when we came up with what we wanted 
in the DRP we said, 'Oh yeah, we can do that in 
the PROM space, no problem.’ But about two thirds 
of the way through the development cycle we started 
thinking about more features like dynamic configu- 
ration, machine-initiated calling and so forth — those 
things take PROM space. So we actually ran out of 
space about two thirds of the way through the pro- 
gram. The real challenge was figuring out how to 
put in all the features we wanted despite the restric- 
tions on PROM space. 




















Bob: When we talk about real estate ... The CPU is 
where the bread and butter is; people buy the ma- 
chine for its performance. So every line of microcode 
we added had to consider the potential impact on 
processor speed, and we had to use it sparingly, 
leaving as much room for the system microcode as 
possible. The main function of microcode is to make 
the DG macrocode go faster — not to talk to the 
SCP. So the microcode portion was a significant 
challenge and probably the most difficult part of the 
diagnostic effort. 


On top of that, Viking was our first dual processor. 
That presented us with all kinds of new scenarios. 
When someone says, ‘Examine ACs,’ well, examine 
ACs on which CPU? Or when you have two CPUs 
that want to talk at once, how do you coordinate 
that? On a much smaller scale, our challenge was 
similar to that of the /VS group in that we had to 
build in locking mechanisms and scheduling algo- 
rithms to avoid collisions. The difference is that, line 
for line, microcode is more limited in what it can do; 
and we were up against the limits of how much of 
it we could use. 





How did you resolve the space problem? 


Danny: Well, we kept the code as efficient as pos- 
sible, and we kept optimizing. But the real solution 
was to find ways to avoid having to store code in 
ROM whenever possible — these are the break- 
throughs that made the implementation possible. 


One thing we did was to design in an extended 
powerup capability. Instead of forcing everything into 
programmable parts, this gives us the flexibility to 
grow and expand. Even though we feel we know 
this machine inside and out, we may want to upgrade 
or fine-tune its diagnostic functions at some point 
after it's reached the field. In the future we can use 
the extended powerup to provide additional cover- 
age, or tailor the coverage — whatever's appropriate. 


Bob: We found a similar solution to deal with the 
interface between the DRP and Field Service. They 
wanted the DRP to be capable of calling their com- 
puter in Atlanta and leaving a message when some- 
thing's broken. Today, their specifications for doing 
that are very clear — they know what errors they 
want to be called on, what number to call and so 
forth. But what if they want to change those speci- 
fications later on? 


We felt that hard-wiring this function could be limiting 
in the future, so we added a feature to the DRP that 
lets it downline code into its memory. Then we gave 
Field Service an area of memory in RAM, and let 
them design the code themselves. It's their call center, 
so we let them own that program and that area of 
memory. This is the first time I know of where we've 
had Field Service collaborating directly with us in 
the lab on a section of the project. 





Danny: | should also mention that by the time we 
came to write the code for the system control pro- 
gram, we were completely out of PROM space in 
the DRP. That's when Bob came up with a great 
idea. He said, ‘Since you've got this downline load 
facility for the remote access facility, why don't you 
allocate some RAMs and downline load your SCP 
from the CPU? That saved us IK of space. It may 
not sound like much in the big picture, but when you 
have no space left (laughs), that's a lot of space. 


How was the team set up to develop the DRP? 


Danny: You really can't isolate the diagnostic pro- 
cessor from Viking. It's characteristic of Data General 
to work in small, tightly-coupled teams. There were 
people who, even though they weren't working di- 
rectly on the DRP, were performing diagnostic-related 
tasks on the Viking CPUs and microcode. So a change 
that may only apply to one part could affect many 
other parts, and the people who were working on 
them. 


I knew intimately what was going on with the DRP, 
and others were experts on the microcode environ- 
ment. So we had to arbitrate who was going to do 
what, what was easier for who — because there 
were some functions that could have been imple- 
mented on either side of the boundary — and we 
had to take things like code space into consideration. 
They were under the same type of constraints that 
we were and also ran out of space early in the 
program. And it wasn't because we had planned 
badly. It was just that as we went on we were 
breaking new ground. At times even we didn't know 
what the final product would be. Necessity ... how 
does that go? ... is the mother of invention. 
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Bob: When you have a very interdependent design, 
you try to minimize the linkages to avoid bottle- 
necking someone else's effort. We built a wire-wrapped 
board for that purpose, the first Viking board to be 
designed and working in the lab, so other groups 
could start developing the pieces that had to interface 
with us. So the power systems group was able to 
build the front end of the power supply, which con- 
nects to our diagnostic bus; and Field Service was 
able to write the software that talks between our 
machine and their computer in Atlanta. 


At one point we had someone working at our wi- 
rewrap station with a long wire running into the 
power systems lab, because both sides had fixtures 
that couldn't easily be moved. So he would do a little 
debugging; then run a couple hundred feet over to 
the power systems lab to see if the power sup- 
ply really came on; then run back and turn it off. 
(laughter) 


So the project went well in terms of the relationships 
among the different people on the team? 


Bob: Definitely. It went very well. 


Danny: Whenever any problems came up we looked 
at them from the team’s point of view instead of an 
individual's point of view. It's very easy to stop and 
think about how something affects you. Many times 
we ran across a problem that would be just as much 
trouble for someone else to fix as it would be for me. 
So the decision wasn't how to fix it because we could 
do it either way — it was a matter of taking into 
consideration all the other implications. 





My attitude was, whatever I could do to make it 
easier for everybody else I would do, and everyone 
else had that attitude also. So we all came out of it 
with our sanity. 


We're all highly confident of our abilities here. But 
we all had a great deal of respect for the other 
individuals too. Even though I think I know a lot, my 
philosophy is that as long as you're still alive and 
functioning there's something to learn. And if you 
work in a team environment where everybody covers 
everybody else, you come out with a product to be 
proud of. 
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OCTOBER 


TUESDAY WEDNESDAY THURSDAY FRIDAY SATURDAY 








SUNDAY MONDAY 










Bulldog power system tests in Thermal Engineering. 


DESKTOP laser printers 


announced. 


CEO talks: voice mail announced 
using VMC/2 controller. 


Columbus 
Day 
y Observed 


Viking named 
MV/20000 
(we think). 


United 
Nations 
Day 


Jay M. gets call at 2 am: 
7 /VS runs on Opus, Bulldog. 


The drawings of Opus are from PENGUIN DREAMS AND STRANGER THINGS, A Bloom County Book by Berke Breathed. Copyright © 1985 
by the Washington Post Company. Reproduced by permission of Little, Brown and Company. All Rights Reserved. 

The drawings of Hagar are from Hagar the Horrible's Very Nearly Complete Viking Handbook by Dik Browne. Copyright © 1985 b' 
Features Syndicate, Inc. Reproduced by permission of King Features Syndicate, Inc. All rights reserved. 


y King 
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THE OPERATING SYSTEM 
AS DEBUGGER 


“As far as we know, AOS/VS runs on Opus — 
it's just that Opus doesn't run AOS/VS.” 


(Overheard in the lab) 





In October, an observer in Westboro would have noticed that the population in the engineering lab had suddenly tripled. They were two- and 
three-deep around the Viking and Bulldog testbeds — people from other parts of the building or other parts of the country, all of them working 
to bring the machines to life. The tables were littered with coffee cups and schematics. Occasionally parents came to work with their children 
in the early evening to put in a few extra hours. There was a day shift, a night shift, and sometimes a few bodies asleep on the floor when 
the two overlapped. And one morning at 5 a.m. there was champagne for all present when AOS/VS ran on Opus for the first time. 


People refer to this phase of a computer system's development as debug. In the following interview the manager of Operating Systems 
Development explains what that means, and the role played by the operating system in the process. 


Could you talk about the point at which hardware 
and software come together in the lab ... What stage 
are you usually at when that happens? 


It varies. The /VS multiprocessing function involved 
10, maybe 15 man-years of work, much of it done 
by people who never touched the hardware. Some 
of them designed utilities, others adapted the file 
system to a multiprocessing scheme. These people 
don't need the hardware to tell if their piece works: 
they can test it with software tools, debug it, and 
they're done. Others have to have the hardware, the 
teal McCoy. Those are people like the /VS kernal 
designers or the device drivers group, who worked 
on components that function interdependently with 
the machine. 


Ideally both sides, hardware and software, will work 
out most of their own bugs before they try and play 
together. So with /VS multiprocessing, we did as 
much testing as possible on an existing MV — ac- 
tually a dual MV/4000 that the hardware group built 
for us while Viking was still in development. Mean- 
while, the hardware group was and his team were 
debugging Viking with MV System X — a very com- 
prehensive diagnostic, sort of like an operating sys- 
tem, but designed to exercise the hardware and look 
for failures. You may be familiar with the diagnostics 
we use in the field, whose goal is to make something 
work again. Well, with MV System X, the goal is to 
make it work in the first place by beating the hell 
out of it to see if it breaks. 


Maybe you can tell me what the software developers 
mean when they say “AOS/VS is debugging the 
hardware.” 


Actually, we say 'AOS/VS is the diagnostic.’ It's 
meant a little sarcastically, as a comment on those 
times when the hardware is ready to be debugged 
but the diagnostics aren't sufficient to debug it. MV 
System X does a very thorough job of exercising the 
basic MV instruction set, so if your machine runs the 
whole sequence you know you've built an MV. But 
in the case of the November products — particularly 
the workstations — there were so many new pieces 
to deal with at once: a new I/O system, new graphics 
instructions, a whole raft of architectural differences 
from the vanilla MV. The best way to verify all that 
new logic, at least from an engineering point of view, 
is to try and use the thing. And how do you use it? 
Well, you bring the operating system in early — 
maybe too early, from a software point of view. So 
that's what that saying means. 


I take it there are both advantages and disadvan- 
tages to using the operating system this way? 


There are bound to be problems any time you bring 
up a new system, but when it hasn't gone through 
a rigorous set of diagnostics ... Using the operating 
system to debug it can be a nightmare for us because 
it's not technology-intensive — it's labor-intensive! 
When something goes wrong, it requires an individ- 
ual to analyze each and every case, to backtrack 
literally through hundreds of thousands of instructions 
to figure out what went wrong and why. 


And the operating system isn't designed as a tool 
that backtracks, like a diagnostic ... 


It's not. The operating system is designed to say, ‘If 
you want to move this from here to there I'll move 
it from here to there.’ It doesn't check to see if that 
happened. So that later on in the logic flow of the 
environment, it may say, ‘Now I'm going to use that 
data I moved,’ and maybe the data wasn't moved, 
maybe only a portion of it got moved — the results 
are undetermined. At that point anything can 
happen — you can branch off into the twilight zone 
with no idea of when you got there, how you got 
there or why. All you have are pieces and frag- 
ments — a few clues that allow you to backtrack 
and put the puzzle together. 


Few people have a broad enough knowledge to pick 
up those clues and then go find the person with 
expertise in that area. Those are the key people. 
They have to be on call for each problem as it occurs 
and to stay on it until it's resolved. They may work 
48 hours at a stretch on one problem, which is tough 
when you're trying to do that logical-level rollback 
on the code. They're tenacious — not nine-to-fivers 
but whatever-it-takes kinds of individuals — and when 
the rubber meets the road, that’s what you need. 


It sounds like an arduous process — but I've seen 
an incredible energy and excitement during this 
phase, when all the design groups converge in the 
lab ... can you explain that? 


Well, there are milestones, and there are milestones. 
Running AOS/VS on a new processor is a milestone. 
When you come up and run Contest, our confidence- 
testing program, it’s not just a CPU in a testbed 
anymore. It's a system. Where before all we had 
were the pieces and parts, now we get to see it 
work. 
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That's one part of it. Another thing ... Throughout this 
whole process, whether you're hardware or software, 
there comes a time when someone steps up and says 
‘This is your problem.’ Then it's incumbent on you 
to prove that it isn't. We all take pride in our work, 
none of us likes to be told it isn't perfect. So we get 
into these score-keeping scenarios — ‘It's got to be 
a hardware problem because we haven't found any 
bugs in /VS.' ‘Well, we found one a month agol’ 


With Viking we were fairly confident about AOS/VS 
in the single-processor mode because, after all, we'd 
already tested it on another MV. Our attitude was, 
‘Your machine's broken, go away and fix it.’ Later, 
when we finally got on the dual-processor and it was 
new territory for us ... then we weren't quite so sure 
whether a problem was software, hardware, micro- 
code or whatever. 


It was a night and day difference, though, debugging 
CPUs and AOS/DVS: when the operating system is 
new, people are naturally reluctant to accept what 
it finds. The attitude tends to be, ‘Go away and come 
back when you grow up.’ Whenever something blew 
up the response from the CPU team was, ‘It must 
be software. If AOS/VS can do it, why can't you?’ 
That got the /DVS group saying, ‘Let's show those 
guys we know what we're talking about — there's 
a bug in that machine and we'll prove it.’ So they 
dug in and did all their homework until they knew 
they were right. Not that /DVS was flawless ... But 
because it handles some things differently from /VS, 
it uncovered errors that might otherwise have gone 
undetected. 


On the Bulldog program, for instance, /DVS found 
a significant number of problems after /VS was al- 
ready up and running on it. Often they were small 
boundary conditions that /VS might hit once in a 
year ... whereas /DVS ran into them after 30 minutes. 
Likewise, Unix revealed problems that the other two 
operating systems couldn't. Each operating system 
shows you something new, simply because they all 
do things a little differently. 


Which brings up another saying you might have 
heard from Tom [West] or one of the developers: 
‘The operating system is the best diagnostic.’ That's 
because it represents as close to a normal operating 
environment as you can get. When we ship a ma- 
chine to the customer, he’s going to run applications 
on it, not diagnostics. And guess what — the platform 
for those applications is the operating system. 
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The term kludge, derived (we think) from the Swedish for "mess" or "pile of straw’, first appeared 
in a series of Datamation articles in the 1960s. It refers to things jerry-built — usually, but not 
limited to, works of computer hardware or software. A coat-hanger aerial is a kludge. 


Seldom a term of endearment, a kludge should not be confused with a hack. A hack can be 
either good — as in “What a neat hack” — or bad. A kludge is only ugly. Our choice for 
Kludge of the Year? It's a tie ... 





“We still don’t know what caused it.” — Opus project engineer 


This socket adapter, part of the first Opus microsequencer, was designed to 
solve a problem that cannot occur. So sure was the vendor that this could 
never happen, they guaranteed it: the pins on the integrated circuit will 
always match the pins on the PC board. 


The kludge was built by hand-wiring pin | to pin 9, pin 13 to pin 97, and 
so on, for a total of 179 pins. To make it more interesting, the only person 
who knew the right answer was in Japan and didn't speak English. 


Don't worry, they match now. 


A YEAR IN DEVELOPMENT 


cl = 


gm ae a . 
rr i. 
Sy G 
> 
ne , 


nt 


te 





"I think ours is the most interesting.” — Viking program manager, 
after learning of the tie. 


Viking may be famous for its single-board CPU, but did you know that the 
original version had as many as five boards? Five daughter boards, that is, 
which plugged into five sockets where the working gate arrays were supposed 
to be. 


We were particularly impressed with the unique L-shaped card on the left 
(and you thought all PC boards were either rectangular or square!). This 
one, known simply as "Fred" among the designers, was a work-around for 
the ALU array whose register files were being mended at Motorola. 


Ugly it may be, but the original Viking CPU was in service a full year-and- 
a-half — longer than the finished CPU as of this writing. Now, if they could 
just figure out how to fit it in the chassis ... 
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TO THE WALL 


Upstairs in the engineering lab FIDOS was struggling with peripherals 
and everyone was struggling with FIDOS; Kite was respinning the Kestrel 
chip; Viking was running MV/System X; and Bulldog, Guss and Opus were 
trying to run AOS/VS. Downstairs /VS was executing performance tests 
on a dual-MV/4000 testbed; the windowing subsystem was being debugged 
in one lab and integrated into AOS/DVS in another — and DG/View was 
trying to run on top of both of them. The Viking FPU came up from Research 
Triangle Park to work with the other boards. Unix was down south trying 
to support all the new processors. The Data Dictionary was almost finished. 


The naive manager looked across this spectrum of activity and tried to 
impose order; the more experienced simply contained their anxiety and 
kept out of the way. One morning a customer toured the engineering lab 
(where a large map of all the pin assignments in a Viking gate array 
stood in plain view with the message, ‘Touch this and I'll blow your ---- 
head off’) and was overheard to ask, ‘Who manages them in here? How 
do they know what to do?’ With a November announce date to meet and 
three months to ship, the answer seemed obvious: keep your head down 
and debug. 


"The Operating System As Debugger" described the process in words. Now, 
a few scenes ... 
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BENCH STRENGTH 


No one talks much about the quality of performance when a computer system is in the early stages of debug; the issue is getting it to 
perform at all. But now, at the end of October, AOS/VS was up and running on all the new machines, and it was time to start qualifying 


their performance in terms of real applications. 


Most computer manufacturers run one or more benchmarks for this purpose, but hardly any have agreed on or enforced rigorous standards 
among themselves. For this reason, it could almost be said that benchmarks are to the computer industry as the EPA is to the auto 
industry — including the fact that ‘yours may vary.’ 


In October a new Performance Analysis group was formed to deal with this issue. They started by developing a rigorous and useful suite 
of benchmarks for the new machines, providing hard performance data that impacts Data General's ability to sell a system, or the customer's 
decision to buy it. But what makes this group unique in Data General, or in the industry for that matter, is the role it plays in bridging the 


communications gap between the vastly different disciplines of 


engineering and sales. In the following interview the group's manager 


explains how bringing the concerns of one organization to the attention of the other can lead to optimal systems performance — in the lab 


and in the field. 


a 


What's the fundamental issue of performance anal- 
ysis? 


The goal is to win business by convincing people to 
buy DG systems. The way we do that is to find out 
the activities customers want their computer systems 
to carry out, and how to get the machine to perform 
them most effectively. If you can make the machine 
run faster, and provide data to back up performance 
claims, the sales force is able to deal from strength. 
That's the end objective. 


To do this, the performance analysis group deals 
mainly with two major customers within DG: the sales 
force and the development organization. We work 
closely with both groups and try to act as a liaison 
between them when dealing with an issue. We run 
customer benchmark programs for the sales force 
and provide some analysis so the customer can get 
the best performance for his application. This involves 
talking with the engineers to identify the problem 
and find possible solutions. We have a lot of inter- 
action with both sides. 


That interaction, between customer concerns and en- 
gineering implementation, means that our engineers 
are better able to understand a problem and come 
up with a new idea. So we're there to be a forum 
for development — to achieve maximum performance 
out of a product as it pertains to the real world. This 
way, when a new product is released, we hit the 
ground running on both sides: design and sales. 





Your group hasn't been in existence very long — 
how were these functions performed by DG in the 
past? 


Customer benchmarking was largely considered a 
sales support issue. Field SE’s ran benchmarks in 
the field or in conjunction with the facilities in Guest 
Marketing. But under those circumstances it wasn't 
easy to get a good overall view of performance, and 
access to the developers to answer questions and 
engineer solutions was difficult. Also there was usu- 
ally no specialized support for the benchmarking 
activity, so results were difficult to understand. 


Within R & D, performance testing takes place in 
both the development groups and the Quality As- 
surance [QA] department. The problem is that QA 
has to take a long view and can't be expected to 
react to a customer benchmark in real time; and the 
developers don't have links to the customer to see 
performance issues in the real-life scenario of a sys- 
tem running some application. 


So your group was formed. What was your charter, 
and how did you develop your working relation- 
ships? 


We were very fortunate, depending on your point of 
view, to be able to work with a new set of products 
during the announcement cycle. Those products used 
new technologies that were untested in the real world. 
So before we got into any real situations we had to 
do some quality assurance work — something new 
for DG in the sense that we looked at it from the 
performance perspective. 





People in my group were able to work directly with 
hardware and software engineers. Where the func- 
tionality rises and falls, we had to decide if everything 
possible had been done to optimize performance. We 
tried to narrow problems down and then call in 
specific engineering groups to find out whose func- 
tions should be improved on. Working in that kind 
of environment gave us a very fast turnaround — 
there wasn't a lot of administrative stuff or manage- 
ment meetings, it was all very efficient. Then, as we 
started to do customer benchmarking, we already 
had some idea of what performance to expect, and 
more importantly, we had an excellent rapport with 
the development people. Most of what was done was 
invisible because we wanted it that way. 
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The engineers started to have a much better look at 
what their machines would be used for since there 
were real customers there. It was a very motivational 
thing. And they learned a lot because they got an- 
swers from the horse’s mouth. We wanted to facilitate 
that communication — we didn't want to stand in 
between by saying to development, ‘Tell me what 
you want to ask the customer.’ Any programs we do 
in fundamental analysis we set up with the engineers. 
We don't propose what's right or what's wrong with 
a product — we all agree on the methodology. And 
then the results are ours — not yours versus mine. 
That has been part of the success | believe. 


At a recent conference you gave a presentation to 
the Central Processor Development group in which 
you challenged the group not to believe rumors 
about performance but to come to you to find out 
what the real story was. What sort of response did 
that elicit? 


I think the speech helped them to understand what 
we're doing. At first they'd come to us with questions 
like ‘How can I make the US Steel benchmark run 
faster on my machine?’ We'd try to interpret the 
question in terms of customer applications: ‘Do you 
mean what can we do to enhance COBOL perform- 
ance?’ Well, we're talking about a commercial ap- 
plication in a certain type of system environment and 
some set of customer priorities. So you see the the 
question shifts to, ‘What really matters to the cus- 
tomer?’ Now they come to us to find out the right 
question to ask. 


It's getting them to ask the right question in appli- 
cations performance terms, so it can be fixed in 
system performance terms? 


Right. Our objective is not only to have a maximum- 
performing CPU or a maximum-performing disk drive 
— it's to have a maximum-performing system. We 
can help people put the issue in a systems context. 
We provide a forum within R & D that bridges the 
gap between different disciplines — we can make 
a CPU designer aware of what the operating system 
is doing, or what disks are doing. The goal is to have 
those people talking together — we're facilitating that. 











If it's on a straightforward enough level, there's a lot 
of efficiency. If you get hardware and software people 
at the machine at the same time talking about an 
issue — it may not bear immediate fruit, but later 
on someone benefits from that experience. The im- 
plicit future payoff is incredible. 


So in an optimized development organization there 
should be a tremendous amount of interaction be- 
tween people from the different disciplines. 


There has to be a connection point so everybody 
can talk together about the issues. And if we can 
show context both for the system and the customer, 
that has a big motivational impact. When you build 
a 12-MIPS machine like the MV/20000 II, you say 
'12 MIPS — wow,’ but it doesn't make an impression 
until you see what a real customer gets out of it. It's 
a shock for most people to go out and see this 
machine running production planning for a whole 
manufacturing organization. That's when CPU power 
comes into context. 


We can also help to set specific goals for perform- 
ance. The goal might be to get x number of CEO 
users on the same machine, and when you reach 
the goal everybody's happy — marketing and sales 
and the development people. Having a goal-oriented 
organization increases satisfaction. 





How has the relationship with the field devel- 
oped — that’s consumed a lot of your time, running 
customer benchmarks and so on ... 


Both sides had to learn. There's a lot of skepticism 
about what can be done by running a benchmark. 
If you run a benchmark on a machine with no spec- 
ialized support the result can seem meaningless. So 
why do it? If you don't structure it, you'll never win. 


By doing it in a more structured way — the way the 
field comes in now, we can provide some support. 
Whenever we run a benchmark, we give them a 
report explaining why the benchmark ran that way. 
If there's a problem with the benchmark, either with 
performance or functionality, we can usually fix the 
problem in a couple of hours rather than months 
because of the working relationship we have with 
the engineers. The field is very happy with this — 
we've been able to have an average response time 
of about one to two weeks. We have even responded 
to benchmarks requiring large configurations — on 
the order of the MV/20000 II with 11 spindles — in 
one week. 





How do you expect your relationship with the field 
to change as you move from being a raw bench- 
marking group to becoming more involved in per- 
formance analysis of system optimization to run 
applications? 


I think it will only get better. Nobody likes running 
a benchmark — it's a lot of blood, sweat and tears. 
But we have to do it because it's the only way of 
explaining to the customer that he'll get a good 
product. And it provides a very convincing argument. 
However, there are plenty of cases where we would 
not have had to run a benchmark if we could have 
provided a thorough performance analysis of our 
systems, backed up with the results from a lot of 
applications drawn from our installed base. That 
would allow the salesperson to sell himself out of the 
benchmark, increasing his productivity. 





So basically you want to get ahead of the game ... 


Yes, but before you can get ahead of the game you 
have to understand what the game is. So I'll never 
give up customer benchmarks because that’s where 
the rubber meets the road. 


And what we've done so far ... We have a set of 
100-plus programs that are representative of our cus- 
tomers’ needs. For the first time we're able to put a 
new machine through all that testing. So the chances 
of anything going wrong with an application on the 
new machine are extremely slim — slimmer than 
ever before. We've run these programs in advance 
— the machine has seen customer operating systems, 
and every time we find a problem it's in the lab, 
before the machine ships, so it gets fixed. This pro- 
vides a level of functional reliability that goes one 
step beyond what's done with normal QA. 


The people in your group must possess a special 
set of skills because they're dealing with very tech- 
nical people, people with broad-based systems back- 
ground, and others who are involved in a business 
situation. They've got to be able to communicate 
with everyone, and have the self-confidence to go 
ahead on their own and know that they should have 
the last word. Can you go into that? 


Each person we hire specializes in a particular sys- 
tem area. We have to teach them to look at the whole 
system, yet at the same time they have to hone in 
on whatever problem is preventing them from getting 
more speed out of an application. It could be lan- 
guage runtimes to instruction execution speeds, or 
disk accesses to file systems. It requires objectivity 
and discipline from our people not to go after their 
pet peeve every time. The problems are complex, 
and it's lonely, because there's usually only one 
person who's working to solve it. 


The outcome is entirely up to them and we have to 
fly by their word. They have to have the courage to 
make commitments before they know what they're 
going to find. Conversely, it also requires teamwork, 
because at a certain point they'll need help from a 
colleague or from another discipline like R & D, CSS, 
or QA, and they have to manage that relationship 
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successfully. They have to be knowledgeable enough 
to be able to tell the languages person, ‘This is the 
block in your runtime environment that's bothering 
me — | just changed something.’ And they need 
good people skills as well — they can't tell someone 
he's all screwed up, they have to be diplomatic. 


So these are complex skills. What they get in return 
is a view of what machines are built for that can't 
be learned anywhere else. And it comes in a con- 
centrated form: a field SE with ten years’ experience 
may have seen all this, but may not be up-to-date 
on every problem. Here situations come up once a 
week — there's never an end to it. 


One of the ironies is that you win and lose at the 
same time — it's like sales. You struggle for months 
to get the customer to buy, then one beautiful day 
you get the order. So you invite everyone to the bar 
and have a ball. But the next day you're back to 
square one again. The highs are high and the lows 
are low. And it's bloody hard work in between. 


Your own background in the industry is very broad. 
What's required to be successful in your new role? 


In some ways it's like marketing — you sit between 
R & D and sales. You plan more and try to anticipate 
what will happen in the marketplace and what func- 
tions you'll need, and feed that back to development. 
The difference is that now we win or lose business 
based on the benchmark. 


You can't do this job if you don't understand how 
all the different system components fit together, but 
more importantly, it's understanding how the engi- 
neering organization works. The same goes for 
sales — you have to understand how the sales or- 
ganization works including the sales cycle situation. 
With some benchmarks we may think something is 
obvious, why do we have to prove it to the sales- 
person? Well, if it gets the order, we'll do it and not 
argue. You have to have a feel for both kinds of 
organizations to be able to do this. I don't pretend 
that I know machines or that I'm a good salesperson 
— it's a matter of understanding what both groups 
are trying to accomplish, and then making it all work. 





In the past it was easier for a salesperson to explain 
to a customer what a computer could do. And it was 
easier to describe to the engineering organization 
what was needed. Now it's different — it's very 
difficult to explain the complicated technology to cus- 
tomers, and to communicate what's needed to de- 
velopment. That's where our group comes in — we're 
in the communications business and we put real data 
behind our explanations. What does it mean to have 
more throughput? How do I prove to a customer that 
we have more throughput? — because it's only after 
he's convinced that he'll be ready to pay for it. And 
what does the engineer have to do to get more 
throughput? It's a matter of asking the right questions 
of both disciplines, and relaying answers in a way 
that's understood. 
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Autofact Show: GM MAP demo 
integrates gear from 21 vendors. 
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PC World readers vote DG/One 
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XODIAC, /VS and Unix revs 


.. all in one day. 


18 


Mike visits Beneficial. 


Thanksgiving 


28 


A YEAR IN DEVELOPMENT 





ONCE IN A 
SN AeN ey 


On November 18th., the day of the new product announcement, the corridors in Westboro were oddly quiet. 
Some of the developers had boarded a bus for New York City the night before and, with their wives, husbands 
and friends, had taken in a Broadway show, dined at Regine’s, and watched the announcement in dress 
rehearsal at Christy's amidst the Picassos and Manets. Home again the next day, they slept in, woke late, and 
enjoyed an afternoon of personal freedoms and unhurried pleasures. In that brief ‘time out of time,’ it was 
almost possible to forget the months of strain that went before and the problems still waiting to be resolved. 


The “November products,” as they came to be called, distinguished themselves in many ways. In quantity, they 
represented the ambition and diversity one would expect of companies several times larger. In quality, they 
demonstrated a thorough mastery of new technologies. by the economy and elegance of their design. In 
performance they ran well ahead of the power curve, proving there was still plenty of headroom for the basic 
minicomputer program architecture. And despite a wave of counter-announcements launched by competitors, 
they retained their competitive advantage. However, perhaps the best introduction to these products, showcased 
on the following pages, comes from Edson deCastro’s first words to the press on that November day: 


“Good morning, ladies and gentlemen, and welcome to the most important announcement in our history.” 
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INDUSTRY’S SMALLEST, 
FASTEST SUPERMINI... 


We built the ECLIPSE MV/20000 small without sacrificing speed, and designed in manufacturability and 
reliability without sacrificing cost. The result isn't just another price-performance winner, but a new 
industry standard in supermini design. 


The MV/20000 uses Motorola's second-generation 2800-gate ECL/TTL arrays, the 
industry's first application of this technology. Each array integrates more circuitry 
than the entire original NOVA. 


The CPU delivers over 6 MIPS of power, more from one board than any 
other supermini CPU. It uses 15 ECL/TTL gate arrays, a hybrid technology 
that allows two kinds of componentry — the fastest and the most inexpen- 
sive — to be integrated on one 15-inch, 8-layer board. 


The FPU is the fastest scalar float- 
ing-point unit running on a single 
board. It employs 17 state-of-the- 
art 2800-gate ECL/TTL arrays. 


The 8-megabyte memory board 
sets the industry standard for den- 
sity and reliability. It uses 256 kB 
DIP DRAMs on an innovative 
board layout that minimizes length 
of etch and maximizes connectiv- 
ity between memory banks. 


The basic board set, plus 16 megabytes 
of memory and seven I/O controllers, can 
fit in 10 1/2 inches of rack space. There 
is no comparable product available today. 


The MCU/IOC board is the industry's most highly inte- 
grated memory and I/O control system. Its aggregate 
1/O bandwidth is 54.6 Mb/s, and its maximum memory 
bandwidth is 94 Mb/s. The board also contains the remote 
diagnostics capability designed for cost-effective service 
and support. 


The power system is the first commercial application of high-frequency, hybridized, 
distributed power regulators. The regulators are expandable based on the customer's 
power requirements, reducing cost of ownership. A new regulator control technique 
enables balanced load sharing; and highly reliable MOSFETS are used as regulator 
Nall oie 
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OPENS THE DOOR 
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If an MV/20000 uniprocessor is more than 6 MIPS, what do you get when you add another CPU? For 
many tightly coupled multiprocessor systems, one plus one is significantly less than two because the CPUs 
aren't equal — only one of them, the master, can execute system calls while the other, the slave, may sit 
and wait. The MV/20000 dual-processor delivers 12.5 MIPS to most applications because of AOS/VS rev. 
7.50 — a major enhancement of the operating system that supports two or more CPUs. Although some 
system calls execute only on the initial processor, 80 percent of those requested can execute on either 
processor — a nearly coequal multiprocessor scheme. 


ECLIPSE MV/20000 dual processor 
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One 61" x 35” x 40” high supermini chassis holds the first CPU and FPU, the second CPU and FPU, 
3 I/O channels, and 64 megabytes of memory, up to 25 I/O controllers, and two 592- megabyte 
disk spindles, with six power regulators for a maximum of 2600 watts. 


From the user's point of view, an MV/20000 multiprocessor looks and acts just like an .MV/ uniprocessor. 
The operating system handles load and memory balancing automatically, and the CPUs schedule themselves. 
Going from uni- to dual-processing requires only a CLI command, and if one processor fails, the system 
can be manually rebooted using the other. The MV/20000 upgrades to nearly double the compute power 
of a uniprocessor system by just adding another single-board CPU — no software changes required. 


In practically all applications, the MV/20000 peer/peer relationship gives better results than master/slave 
systems. And though most multiprocessor manufacturers want it in their systems, few have it, because 
realizing this type of environment is quite complex: it takes identical hardware components to produce the 
necessary runtime environment, and operating system software that lets both processors schedule jobs and 
access devices. In overall ratings among competitive products, this is one of the fastest systems with the 
lowest price per MIPS; perhaps more important, it is neither incompatible with existing user programs nor 
limited to highly specialized types of compute. Although it's not the only solution, the MV/20000 is the best 
one for hosting a complete range of applications, from compute-intensive to data processing and highly 
interactive jobs. 


A YEAR IN DEVELOPMENT 





THE TRADITIONAL 
WORKSTATION DESIGN 


.. Where each subsystem is designed by a different group of engineers on different chips or 
boards — easy for a large company to manage because the groups only need to communicate to 
a limited degree. But this kind of philosophy builds walls and defines parameters that place limits 
on the design organization. Because the design can't be optimized across the whole system, efforts 
and functions are duplicated and the result does not produce the best product. 


Disk controller board 


Typical Workstation Architecture 


Memory Bus Intermediate Bus 


Device Buses 


Tape controller er 


LAN controller board 


A typical 32-bit CPU board with a CPU chip, FPU chip, read- 
only memory containing the instruction set (or some subset), 
some random-access memory, and circuitry required to in- 
terface the CPU with the rest of the system. 


Several independent controllers hang off of the I/O bus, each 
with its own processor, ROM firmware, buffer RAM, controller 
circuitry, jumpers, dip switches, and so on. Each controller 
requires a microprocessor and lots of bus interface logic. 


LAN controller board, in this case using an 8515 and LSI logic 
arrays, and many more chips to generate bus logic. 


Tape controller board, in this case using an 80186 as the 
controller, plus circuitry to interface with the I/O bus. 


A YEAR IN DEVELOPMENT 





INDUSTRY'S FIRST 
2-BIT SYSTEM BOARD 


.. A much more difficult process — the entire system is designed on one board by one group of 
people who must work closely with each other. But the result is worth the extra effort: better 
performance due to tightly integrated functions; higher reliability from fewer working parts; and 
lower cost of ownership because one board contains no less — and no more — than what you 
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A single system board is the heart of Data General's new workstations, the DS/7500 series 


and the MV/2000DC. 


DS/7500 (No Bus) Architecture 
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Single-board 
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1/0 Controller 


Industry Standard Device Buses 


Oo The CPU is implemented in three 8000-gate CMOS arrays, 
the FPU in a fourth. 


(2) The entire instruction set is implemented in writeable, 
RAM-based control store — commercial instructions, 
graphics instructions and intrinsics. Future enhancements 
are easily loaded. 


(3) Two megabytes of on-board memory. 


Standard, commercially available DMA controller chips 
do the work of tape, LAN, and disk controller boards; they 
generate the SCSI interface; and drive a 96 TPI floppy, 
parallel printer port, and four DUART ports. 


The controller chips use this section of buffer RAM to 
create a “local bus” — a direct connection between pe- 
ripherals and main memory. So I/O devices perform at 
memory bus speeds (12.5 Mbytes/s). 


(6) An Intel 80186 supervises the completely integrated I/O 
subsystem. 
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“UN”’PACK AGING 


When most minicomputer companies design a workstation they take what already exists 
and repackage it — it's easier that way. The result is an assemblage of parts, some yi 
them unnecessary, others ill-suited to an office environment, and none of them quite as 
well-integrated as they should be. Data General became the exception to this rule when 


it introduced the most thoughtful and innovative workstation design of the season: the 
ECLIPSE MV/2000DC. 
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Complete 
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The MV/2000DC system board has everything that 4 users need 
and it's optimized for business applications: a commercial instruction 
set, fast communications and I/O, generous amounts of memory 


and disk, 4 standard ports. Memory and I/O expansion cards 
support 20 more users. 
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Small 


The complete 24-user system fits in 3 cubic feet of space and is 
easily moved by one person. By comparison, a microVAXII pack- 
ages a 4-user system in 4 cubic feet that requires two people to 
move it, and a 16-user system in a 5-cubic-foot cabinet. 


Elegant 


A few things you won't get from us: heavy-metal fortifi- 
cations, expensive backplanes, and elaborate connector 
schemes — holdovers from classic minicomputer thinking 
but hardly appropriate technology for the office. 
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Simple 


It opens with a nickel and plugs into the wall. The 
chassis has been replaced with rugged structural plas- 
tic. Instead of a backplane, the option boards have 
stackable connectors that plug directly into the system 
board. We managed the complexity so the customer 
doesn't have to. 


Friendly 


No complex powerup and loading of 
operating system software — it's al- 
ready installed on the disk. Just turn 
the system on, follow the CEO-style 
menu and log on. An on-line tutorial 
provides system management instruc- 
tion in an easy-to-follow format that lets 
even the novice feel comfortable per- 
forming system tasks. 
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Inexpensive 


It's the interfaces that you pay for — the extra 
silicon, sheet metal, and cabling that hold a com- 
puter together when it's designed as discrete parts. 
Electrically and mechanically, the MV/2000DC is 
thoroughly integrated so there's very little inter- 
facing. It's reliable because the fewer parts there 
are the less chance that one will fail; and it's 
economical because if it costs less to build, it costs 
less to own. 





PUTTING IT 
ALL TOGETHER 


Graphics ... windows ... pop-up menus and icons ... tablet and mouse ... Unix and TCP/IP ... a local area network 
... applications tools. A technical workstation includes one or more of these things, depending on whose definition 
you go by — but rarely does it integrate them all in one unifying concept. Technical workstations have been 
built from little more than a 68K processor and the Unix source code from Berkeley. Or by connecting a generic 
box to an expensive graphics processor with an async line. Instead of a series of point products and features, 
Data General announced the DS/7500 series — a whole-systems approach to technical workstation issues. 
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AN INTEGRATED SYSTEM 


The DS/7500 integrates a complete MV/ system on a single printed circuit board, including a 1-MIPS CPU; Floating- 
Point Unit; 2MB memory; intelligent I/O data mover; high bandwidth DMA bus; a LAN controller; disk, floppy and 
tape interfaces; four serial ports; a parallel printer port; and a port for SCSI devices. The under-the-desk office 
package holds the power supply and all mass storage devices, so the system expands without taking up more 
space in the office. Instead of a backplane, additional memory cards, optional I/O interfaces and the graphics 
cards stack directly onto the system board, so the customer buys exactly the configuration needed. And with memory 
available up to 10 MB, and mass storage available up to 240MB, there's plenty of configuration range. 


HIGH RESOLUTION DISPLAYS 


Not all applications need a big expensive. monitor, and not everyone's desk space can accommodate one. The 
DS/7500 series offers a choice of high resolution color (1024 X 800 X 8), very high resolution color (1280 X 1024 X 
8), and high resolution mono (1024 X 800 X 1) monitors available with both 19- and 15-inch screens, keyboard and 
mouse. 


SMART GRAPHICS 


The issue with computer graphics is they're either too slow or too expensive. The DS/7500 
solution — “magic” gate arrays, video RAMs, and a graphics instruction set — Jae) osc deVemcy ciccye0) 
do more, perform better, but cost less. 


The Graphics Instruction Set is a single interface to the medium- and very high-resolution graphics 
adapters shown here. It's fast, because microinstructions execute faster than assembly language. 
It's efficient, because it uses gate arrays that offload the most time-consuming chores from the 
CPU. And it's economical, because it costs about 200 percent less than building a separate 
graphics processor. The GIS also works with both the local video RAM and system memory — 
a requirement for general-purpose windowing. 
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WINDOWS: AN OPEN AND SHUT CASE 


Windows have become a standard applications service on today's technical workstations, allowing 
users to run several applications at a time on a single monitor, moving swiftly from a CEO mailbox 
to a logic design program to a simulation program and back. But many windowed environments 
don't live up to their promise in the implementation. Performance suffers when windows are treated 
as a discrete add-on instead of an integral part of the basic systems architecture. DG's approach 
was to build window support directly into the operating system as a common component, where it 
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can use GIS II for fast manipulation of bit-mapped workstation screens. a _— : 


On the other hand, not everyone wants to design programs to take advantage of windows — they 
just want to run applications in them. The menus, intelligent borders and other features of 
DG/VIEW, a window management program, give the end-user a friendly interface consistent in 
format and access method across all applications. And DG/STAGE, an applications and graphics 
environment, allows users to integrate the software applications of their choice. 


THE RIGHT SYSTEMS SOFTWARE PLATFORM 
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With a choice of operating systems, businesses can optimize the use 
of DS/7500 workstations in their current computing facilities. AOS/VS, 
with its full range of complementary communications software, lan- 
guages, utilities and development tools, provides a powerful platform 
eachiaas for timeshare environments. AOS/DVS transparently distributes the 
oo) resources of workstations, superminicomputers, servers and peripherals 
pre across an industry-standard LAN. Of course, it's completely compatible 


wih ie) zy mS ; with AOS/VS. And DG/UX, provides a native Unix environment com- 
saa cca! Sy PIL "es nar me patible with AT&T and Berkeley Software Distribution standards. 
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A COHERENT APPLICATIONS PLATFORM 


Some workstations are conceived for an environment that doesn't exist, a hive of purely technical 
activity where administrative tasks don't apply. TEO (Technical Electronic Office) software, on the 
other hand, is designed for the majority of technical users who need to move easily between 
engineering, documentation, planning and management tasks along with electronic mail and lode =a 
OA functions. Together with DG/Stage, TEO allows software developers, value-added resellers and 
users to add applications packages while maintaining a consistent user interface. 


Two contemporary applications designed specifically for DS/7500 series workstations with TEO, are 
also available. TEO/Electronics supports electronic design automation with logic design, modeling, 
and simulation software. TEO/3D contains tools for three-dimensional design and modeling. 


Both are representative of the new third-generation design applications, and both use the resources 


of the DS/7500 series — including sophisticated graphics hardware, an integrated window envi- 
ronment and distributed resource sharing — to optimal advantage. 
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DECEMBEK 


SUNDAY MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY SATURDAY 
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Hanukkah 


Andy, Jim and others stage 
new product demo for analysts; 
Rona sleeps in. 


Winter 
Soltice 


Four days of 
heavenly peace 


Pats defeat Jets in wildcard 
on their way to AFC title. 
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IT’S NOT OVER 
‘TIL IT’S OVER 








A product announcement is the most exciting milestone in this business, and the most deceptive. It occasions the kind 
of heady excitement we associate with completion and release — yet a much more important milestone is still ahead. 
At DG they call it First Customer Ship, or FCS: a process of taking a product from development, putting it into 
manufacture, and sending it out the door. 


When asked to sum up their experience of a successful FCS campaign, most people fall back on the same word used 
by athletes, politicians and war veterans: "teamwork." To the casual observer their answer may sound shopworn and 
inarticulate, but those who've been through it know instantly what it means. The work of FCS, which began in earnest 
in December, is remembered less for its singular grandstand plays than for doing the hard, often tedious, and absolutely 
necessary thing — and doing it together. "Teamwork" really means being part of a collective effort, where everyone 
experiences the same pain and the same fulfillment in striving towards one goal. Most businesses lack the emotional 
vocabulary to do justice to that experience; but in the comments of Manufacturing’s new product program manager 





on shipping the MV/20000, you begin to get the idea. 


We're talking about a lot of plants involved in this 
announce. Can you give me an idea of which plant 
did what? 


In the beginning of any program we take a look at 
the locations — where is the best place to build this 
product. Then we designate a prime plant, the one 
responsible for pulling together all the people, parts, 
and materials required to build it. In the case of the 
MV/20000 we chose Southboro: first, because it was 
close to development; and second, because it had 
the most experience with MV/processors. As it hap- 
pened, just about all the plants played a part in the 
MV/20 project: Portsmouth was the feeder plant for 
most of the board activity; Austin was responsible 
for parts of the power system, the BBU and VNR for 
the rackmount chassis; Clayton developed the bare 
boards; and Southboro did the cables and chassis 
build, assembled all the parts from the various fa- 
cilities, and kicked the product out the door. 


What were some of the critical issues in shipping 
the MV/20 from a manufacturing point of view? 


Well, with any program ... Once a product plan is 
defined we hold a design review with engineering. 
And the main thing we look for is testability: how 
well or how easily the design can be tested in man- 
ufacturing and the field. For each logic board we 
hold a review between the designers, manufacturing, 
and field engineering so that if one of us has a 
concern we can try to get it resolved directly in the 
design. The product has to be testable before we 
ship it out the door. 





We conduct tests at many phases — on raw boards 
and assembled ones, with components and without. 
We define the test equipment for each of those 
phases — what we call the fixturing — at the be- 
ginning of each project, based on the rev | boards. 
Most fixturing is rev-locked, which means that as a 
board goes through revisions — and they went 
through many on the MV/20 — so does the test 
equipment. And those changes impact scheduling in 
the manufacturing facility. 
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When you say rev-locked, you mean that this test 
only works for this version of the board? 


Exactly, rev-locked for each one of the boards. In 
the current sequence of things, a design has to be 
stable before we can turn it on and start fixture- 
building. Until then, most of the testing is done by 
brute force: you take an MV/20 board, put it in the 
chassis, and run diagnostics against it — very dif- 
ficult to do on that type of board. Then we may have 
a rack of ECOs [engineering changes] that have to 
be incorporated in a new fixture build. 


In the case of the MV/20, there was such a fast pace 
of debug and subsequent ECO activity that the new 
revs had changes on them before they even reached 
the lab. So there were an awful lot of wires on those 
boards, which are very densely designed to begin 
with. And from a testing point of view, a board with 
150 wires presents a serious problem because it's so 
difficult to probe. Our solution in manufacturing was 
to create extra layers on the pc boards — something 
this company has never tried before. 


The original MV/20 design specified 8-layer boards. 
We had an idea that we could fix the testability issue 
by adding what we called ECO layers. It meant 
taking all the wires generated by the ECOs and 
incorporating them in a layer — implementing the 
design changes in etch instead of wire. This meant 
that we could take a 100-wire ECO, add an extra 
layer, and tum it around in about a week. The 
reliability was high, the testing was a lot easier, and 
once the design was stable we could bring it back 
down to the original eight layers. While other com- 
panies have used this technique, we were trying it 
for the first time. It was a little risky, but it worked. 
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If you've designed the machine to have 8-layer 
boards and all of a sudden you have 10 layers, 
how does that impact the rest of the system? With 
those extra layers, does the board still fit? 


That was one of the things we had to look at in 
determining the feasibility — not only what the im- 
pact might be on the electrical interaction between 
the layers, but the thickness of the board. Each elec- 
trical layer is insulated from the others with a layer 
of plastic or fiberglass, and the thickness of those 
layers is specified in the original design. What we 
were proposing was to mess around with those spec- 
ifications — to compensate for more layers by mak- 
ing the insulation thinner. 





Before we could implement the idea we needed to 
sanity-check it with the engineers, to make sure there 
were no technical reasons why it wouldn't work — 
"What are we doing when we do that?’ ‘What kind 
of mess are we making?’ Then we cross-checked it 
with the fab shop. This was all done within a week. 
We were able to make the decision that quickly 
because of the solid working relationship between 
each group — the fab shop, the Portsmouth facility, 
and the engineers. 


I'd like to talk about that — the relationship be- 
tween Manufacturing and Development. With all 
the pressure on this product, I expected to hear 
some unprintable things ... yet there's been only 
praise for Manufacturing from the developers. 


The praise is reciprocal. Maybe the problems on this 
project seemed greater than others because they 
were crammed into such a short duration. With an- 
other six months, many of them wouldn't have been 








problems at all: the engineers could have concen- 
trated more on analyzing design flaws, and Manu- 
facturing might have gone through one or two 
iterations of test equipment instead of five or six. We 
just had to keep up, get our hands in early. 


Under the circumstances, what kinds of things could 
you do to keep pace? 


In the development of the pe boards — and | em- 
phasize the boards because they're the heart of the 
whole thing — we were able to either use brute 
force or come up with the test fixtures fast enough 
to keep the debugging on track. The engineers didn't 
waste a lot of time debugging bad components be- 
cause we got rid of the gross errors in test, freeing 
them to concentrate on the design flaws. So I think 
we helped out quite a bit there. 





On the other hand, they helped us out a lot. We 
have a bigger organization with a lot more people 
relative to their group. We brought several test tech- 
nicians to Westboro from Portsmouth and they lived 
here for about four months. They helped bring up 
and debug the first MV/20 systems — it was like a 
mini manufacturing lab in CPD. It gave the manu- 
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facturing people some excellent hands-on experi- 
ence, encountering the kinds of problems the engineer 
traditionally deals with. So when they got back to 
Portsmouth the learning curve was very short. Had 
they waited for the product to come to them, they 
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would have delayed the learning process. As it was, 
they picked up techniques that they wouldn't have 
otherwise. Of course, it took a big commitment on 
their part — 11 people working days and weekends, 
a lot of them with families that they just didn't see. 


Their involvement also proved valuable when it came 
time to announce the product — all those people 
joined in the effort to get the show machines together 
because they'd already worked on the sample builds. 
So the whole weight of the announcement didn't fall 
on the engineers — the manufacturing people were 
there to help. 


Overall, having the two groups work together really 
sped up the process. It takes that level of contact to 
pull off a product development; you can't do it over 
the phone or CEO. Then, once the process is over 
and everyone goes back to their respective divisions, 
the contacts are in place; when you need a question 
answered or something done, you know exactly where 
to go, who to call — you know how the other guy 
works. In the past, when that didn't happen, it showed 
up real fast: the program would go into crisis mode 
and people couldn't react because they didn't know 
the other players. 


It's kind of amazing — to have people who are as 
many miles apart as our different groups working 
so closely. This level of involvement has never hap- 
pened before, at least not in my experience. 








Remember Shrike, that MV/ chip set being worked on in Sunnyvale? And that Kite wire-wrap station in Westboro, 
where a few engineers were still plugging away at the back of the lab? Now, eight months later, it might appear that 
little had changed in comparison with the frenzy of FCS activity going on at the other testbeds. But in fact the Kite 
team was getting ready to score a quiet victory as they started plugging real silicon into the system board. 


Finally after all the working and waiting, all the elements of the Shrike and Kite programs had come together. In a 
short time Kite would be announced as the ECLIPSE MV/7800, a single-board system incorporating the custom MV/ 
chip set for the first time. A few days before Christmas, to celebrate the first working chip set, the engineers received 
a case of California champagne. They sent their thanks to Sunnyvale in the form of a long-tailed, autographed kite 
— but most people agreed that Westboro got the better half of the deal. 





BIRD ON THE WING 





“In custom design, circuits are designed right from the logic diagram, whereas in 
semicustom design, the logic comes from macros that the vendor provides. So custom 
design takes a lot longer, but the die size is usually smaller. Because it costs so 
much to process a silicon wafer at a given technology, we try to get the most 
functionality on a die as possible to maximize performance and minimize board 
space. 


"It's not like the semicustom design of a gate array 
where you tell the vendor, ‘Make me a multiplexor’ 
and you know it'll work because it's been checked 
out. Sunnyvale had to design the multiplexor, check 
that it functioned as a multiplexor, and determine its 
speed. Then transistor sizes and line densities were 
checked — on a gate array that's already done for 
you. So more tools are required to do custom design. 
And of course it takes a lot longer and requires more 
people. But it was worth it in this case to get a much 
higher performance on a smaller chip area.” 





"There are times when custom design is a more appropriate technology than others 
.. in a machine like the MV/7800, for instance, that's attractive to OEMs. Those 
S/140, S/120 and NOVA 4 customers who want to upgrade to a 32-bit system can 
now do so — they just take out the existing boards and slip this new one in. So 
potentially it's a higher-volume product, and the custom process allows us to 
manufacture it at the most advantageous cost.” 


"Time is another factor you have to consider in the 
custom process. If it's a market-sensitive product, the 
economics favor semicustom because you don't want 
to spend more than a year or two developing it. The 
MV/7800 was less vulnerable in that regard, being 
a bread-and-butter MV/ ... but even then, we had 
to keep the chip set competitive. Over that four-year 
custom process its performance was more than 
doubled through a series of semiconductor processor 
enhancements, because we wanted customers to see 
a sizeable price-performance improvement.” 


Designers of the MV/7800 in the Westboro engineering lab. 


"To achieve a certain level of performance, you want to put as much on the CPU 
chip as possible and do it fast. You could use a 20,000-gate gate array and still not 
achieve what you could by custom designing. In some areas of custom you can get 
a very high packing density because each transistor is only as large as it has to 
be. For instance, caches eat a lot of silicon area — and those are real performance 
accelerators. So if you can get those on the CPU chip it could really enhance the 
speed. You try to organize your CPU design to take advantage of the circuits that 
take up the least area, so you can use more of these and get more functionality on 
the chip.” 
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"We also wanted balanced systems performance — not just high scores on a Sieve 
benchmark which does no actual computation. The MV/ instruction set has been 
optimized for some time to do well at scientific and commercial applications. But 
you've also got to look at interactive performance, where the CPU may not be the 
limiting factor — it could be memory, it could be the multiplexors, it could be the 
disk. Those functions are nicely balanced in the 7800, and the benchmarks show 
it — our CEO performance is consistently better than other mid-range processors. 
That makes us feel pretty good.” 


“The MV/7800 kind of crept up on a lot of people — there weren't many expectations 
at first, and other products had much more visibility. Now, all of a sudden, everyone's 
excited. They're saying it'll be one of our most popular products because the pricing 
is attractive, the performance is good, it has a wide range of applications ... and 
it's an MV/." 






The MV/7800 — a complete 
single-board system. 
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AND THEN IT'S 


STILL NOT OVER ..._—4 






Even after the first of the new systems left the loading dock, the work of FCS was still going on. What designers 
casually referred to as /VS rev 7 was in fact not one but many pieces of software, each supporting different system 
configurations and functionality. To have all of them fully qualified and ready for the first shipment would have been 
impossible. The solution, as described by the software release manager, was to do the barely possible: to stage a 
series of incremental releases, making the appropriate rev of software available for each new product as Manufacturing 
was ready to ship it. Although he describes a very different process from that of shipping the MV/20000 hardware 
(“It's Not Over ‘Til It's Over"), that word "teamwork" seems to keep coming up in both of them. 





How do you qualify software? 


Let me start by talking about how you do that in an 
ideal situation. If you've got an MV/ already out in 
the field and it's reliable, a new release of software 
is fairly simple because you're only focused on the 
software part of the system — the hardware issues 
are stable. 


The way we qualify in that environment is by having 
the System Development Division's SQA [Software 
Quality Assurance] group and Manufacturing’s DAE 
[Design Assurance Engineering] group take passes 
of the software and run various qualification tests. 
Many of those tests run in batch mode overnight or 
over days. DAE runs acceptance procedures — if 
there are no errors then the software passes the test. 
They also look at what's new in that release of the 
software — what function changed — and write 
specialized tests to focus on that. They run packages 
of stress tests. DAE tests AOS/VS on various hard- 
ware configurations that they have access to as a 
part of Manufacturing. 


SQA, on the other hand, is focused more on the 
software layers — qualifying the operating system 
there. They do that by running layers of software, 
such as CEO, on top of the operating system. And 
then there's the very labor-intensive task of just sitting 
down and playing with the system to deal with func- 
tionality that's very interactive. 
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Another direction we go in to qualify software is to 
run it through alpha and beta testing. SDD's CSS 
[Corporate System Support] organization gets in- 
volved in arranging and coordinating the beta test 
program, and SQA does the same for the internal 
[alpha] sites. We run both kinds of testing for as long 
as possible. 


So there's alpha and beta testing, specific testing by 
DAE, and specific testing by SQA. From all of these 
directions we get software problem reports [SPRs], 
which go to the software developers to be resolved. 
People like myself try to facilitate and coordinate the 
resolution of those reports. There are regular meetings 
to keep the process prioritized and on schedule, where 
we identify "gates" — a problem that would prevent 
shipment — and give those a high priority. When 
we've resolved the problems and there are no gates 
left, we're finally at a point where we have a good 
pass. Then we agree to ship it, and the ball is passed 
to the Software Technical Services group which man- 
ages the release process. 


So that's the ideal situation. What actually hap- 
pened over the past year? 


That's a little more interesting because it was far 
from the ideal case in terms of qualification. There 
was Viking, which was fairly simple relative to the 
others; Bulldog and Guss, each with a lot of new 
software; and then the software for general release 
to our current customer base. 


The way we planned to sign off AOS/VS rev 7 — 
which as you probably know was a major enhance- 
ment supporting al/ the new hardware and updating 
support for current customers — was to break it up 
into several updates and revisions. To support the 
hardware as it was ready to ship, rather than waiting 
until all the hardware was ready and then supporting 
it with one software release. 
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We went through great pains to break it apart ... the 
major break being to make rev 7 support Bulldog, 
and having the subsequent 7.50 revs support every- 
thing else. But we quickly had to become more re- 
alistic to deal with the various problems and 
differences required for signing off so many kinds of 
systems. And as we got to 7.50 and saw all the things 
we had to do to ship in September, we broke that 
down into manageable pieces. 


The way it worked out was in March we shipped 
AOS/VS 7.00/7.01 for Bulldog. In June we qualified 
6.05 for the Viking uniprocessor. In September we 
began shipment of the 7.50 revs. There were four of 
those: 7.51 replaced 7.01 for Bulldog, 7.53 replaced 
6.05 for Viking and supported the dual processor, 
and 7.52 supported Guss for the first time. And we 
deferred the final release, incorporating 


all of these things plus our installed base, until Oc- 
tober — that was rev 7.54. So basically the software 
for the new products was released in March, June, 
and September. Through the entire process we tried 
to respond to business needs to ship systems ... the 
pressure to make those dates was enormous. 





Did the products’ functionality change much be- 
tween revs? 


Yes. The first goal was to support hardware ship- 
ments to the early adopters — customers who want 
to upgrade their current installation. They may need 
an early machine to start planning their facility; or, 
if they're an OEM or VAR, to start developing their 
next product. So we move quickly to qualify these 
orders, determine their software requirements, and 
get them slotted in manufacturing as soon as possible. 








Then we have customers who want the systems so- 
lution: these are usually not the early adopters; they 
want our whole system with all its hardware and 
software functionality. So our early revs contained 
less functionality than the later ones to respond to 
these two different types of customer. 


Of course, there's a minimal amount of functionality 
needed to be able to ship at all. For Bulldog, the 
new user-friendly start-up and the SMI [System Man- 
agement Interface] had to be working reliably so you 
could power up and log on and do something. 


How stable was the hardware schedule while you 
were trying to release this rev of software? 


Back then the hardware and firmware, microcode 
and software were changing daily as testing pro- 
gressed, and all those parameters made the quali- 
fication very complex — you didn't have the nice 
simple environment of a stable system with just the 
software to qualify. It took an enormous team effort. 





We had to be very resourceful to deal with the 
aggressive shipping targets. At the very end we had 
development managers going down to Apex to help 
load the software — to accelerate putting software 
on the disk and shipping it out. We wanted to help 
compress the manufacturing window because of the 
time it took to qualify. 


Was the situation more stable for the 7.50 releases? 


Somewhat. The revs for Bulldog and Guss were par- 
ticularly difficult because there was so much new 
software. We had constant software problems specific 
to all the new code for the user-friendly area, the 
windowing software and the new hardware. By con- 
trast Viking was quite simple even though we were 
under pressure to get it done on time. Throughout 
the release cycle the issues were primarily hardware- 
related ... the software was quite stable. Very few 
problems specific to Viking or the multiprocessor were 
identified in the software throughout the final months 
of release. When we beta-tested Viking we weren't 
really testing the software, we were testing the hard- 
ware system. 








Was that because of all the testing that had gone 
on with the multiprocessor software during its de- 
velopment? 


For a long time before we got a Viking we had the 
test-bed environment — the dual MV/4000. Any soft- 
ware problems were of a general nature, not specific 
to Viking. 


Who were the people responsible for the various 
products’ software? 


Viking went to beta test supported by AOS/VS 6.05 
and at that time John was working with the hardware 
developers and Manufacturing to resolve issues and 
get the thing out the door. The next shipment of 
Viking support was led by Michelle. Ken was the 
leader in troubleshooting Bulldog problems. And | 
was the coordinator for Guss. To manage all the 
updates we had development and support groups 
meeting anywhere from a daily to a weekly basis 
— sometimes even on Saturdays — to make sure 
everyone was working on the right stuff. 





Who attended the meetings you were holding? 


Most of the section managers would attend along 
with project leaders, and we'd have representatives 
from QA, DAE, Manufacturing, Documentation, STS, 
CSS, and so on. The people ranged from individual 
contributors to directors as they were needed. ... At 
one point we were passing out beepers to various 
folks so everyone could keep on call. 


So you'd fix problems, then distribute a fixed version 
into testing, and they'd come back with more re- 
ports? 


At times the pace was so intense that we were making 
passes daily — in some cases multiple times a day. 
We'd agree to cut a pass on a particular day, and 
the pressure was on the rev coordinator and the STS 
people to get it done. They were being asked to do 
some unreasonable things in the time allowed, which 
created an environment for error — sometimes they 
had to restart the process many times on a particular 
day. They would cut the pass and distribute it to 
DAE and SQA only to find that something was wrong. 


Things were so hectic because we were pushing the 
process as fast as we could. When we finally got 
beyond the separate shipments of /VS for Guss, 
Bulldog and Viking — we were able to start pacing 
ourselves. Our preparation was more calm and care- 
ful as we worked for qualification of 7.54. And that 
made a big difference. 


Do you still have the beepers? 


We turned them in a few weeks ago (laughs) — once 
we got past the end-of-quarter shipments. 


What were the most important lessons learned from 
going through this effort? 


Flexibility and teamwork come to mind right off. We 
had to be very flexible in our idea of how to release 
the software, which became very different than the 
norm. The business needs became foremost in every- 
body's mind, and we readjusted our process and 
schedules to meet those needs. 


The teamwork I mention because, particularly in the 
meetings I've been holding, I've realized that we'd 
be making no progress at all if not for the fact that 
all the different organizations agree on the basic 
objectives, and we're all working together and com- 
municating. We're working as a team to identify the 
right issues and get them resolved. 
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COMING 
HOME 


And then one day you notice an absence of something. 
There are no more schedules to drive at; no more urgent 
messages waiting at your desk. You continue to see 
people you've spent more time with than family; but the 
action items and open issues that brought you together 
have been resolved. No one ever really says, “It's over,” 
the intensity just sort of slackens. And you find yourself 
letting go of a project that may have occupied you for 
years. 


A number of developers have described the act of build- 
ing things as a perpetual draw: the challenge of making 
it work keeps them going; the satisfaction of seeing it 
work is the reward. But if the emotional peaks and valleys 
of this process were described on a chart, the time 
between the last project and the next would look like a 
trough. 


People handle this in ways that are probably too per- 
sonal and complex to put into words; still, we asked 
them to try anyway. 


Almost everyone emphasized the importance of knowing 
there's another project waiting in the wings. 


Some called it “a stamina game.” 


Others said “I pace myself,” or “I can manage myself 
through it because I've been there before, I know it's 
coming, and I know it's only a matter of time before I'm 
onto something new." 


A few people said that finishing a project was the best 
moment for them. 


And one engineer said, "My manager tells me, ‘Go 
home.’ That's where the tension gradually starts to lift. 
Taking it slowly, getting back to my family and things 
I've wanted to do for months, I hit a different stride and 
feel like a new person — the person | was before this 
project started! Then I’m ready to sign on and do it all 
over again — maybe | should have my head examined." 
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UNTOLD STORIES 


While the products in this book were being developed, there were many more initiatives underway that we didn't 
record. Some of them were building the next generation of Data General's product line. Others were pioneering efforts 
on new technologies that would eventually pay off in real products. There were also countless untold moments 
representing important milestones for the development community. The following pages capture a small sampling of 
these projects and events. 





THE FIRST NEW SYSTEMS LEAVE THE DOCK 


The first Bulldog and Viking systems were shipped to customers from the Apex, N.C. and Southboro, MA. 
manufacturing plants. The project leader for Bulldog had the satisfaction of seeing his system being prepared 
for that moment on a visit to Apex, as the machines were being assembled and tested. 


"I'd been down there six times since Christmas,” he said, “but on my last visit I was really impressed. The 
technicians showed me a Bulldog they'd modified so you can just slip a disk drive in the front, dial up 
the type of drive, and automatically copy the operating system over to it. In five minutes they'd loaded 14 
megabytes worth of /VS onto a Winchester and had Contest running by the time it got down the line. At 
the end of the assembly line they'd built an area where they plug in the machine, run System X and burn 
it, all monitored by computer so they can track how many errors and how many hours it's run. The machine 
never leaves the line until they know it works. When I was down there | watched 500 Bulldogs all running 
different diagnostics, just sitting on conveyor belts in the middle of the floor. Incredible. I'd walk around 
from machine to machine and talk to people. They were really excited, not just putting in their time and 
going home. They really cared about what they were doing. It made me feel great." 








ADVANCING THE OPERATING SYSTEM 


While multiprocessor and windowing technologies were being folded into AOS/VS, another design team 
was advancing the next generation of operating system enhancements. Their efforts were wide-ranging: 
from availability features to embedded support for Unix and symmetrical multiprocessors. 


Their work concentrated on the ‘R’ in R & D, investigating these and other software technologies and 
building the foundation for future OS components. 
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YOU NEVER OUTGROW YOUR NEED FOR MIPS 


Meanwhile a group of designers from the engineering side 
of the house spent the year in development driving the 
high end higher, with a suite of systems aimed at large, 
commercial computing environments. While Viking, Bull- 
dog and company were in debug, they were testing their 
first gate array. And by the time the other projects were 
winding down, this one was getting ready to go to the 
wall. 
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A SILVERWARE ANNIVERSARY 


It's true: the symbol for a fifth anniversary is silverware. As you might expect, 
there was a certain amount of that on hand at the dinner party held in Boston's 
Quincy Market Building to celebrate the fifth anniversary of CEO. Awards were 
presented to the 10 CEO contributors of longest standing, those of whom worked 
on the original product. For a speech looking back on five years in development, 
the director of User Systems went to the history books to find other productivity 
aids introduced on a November 17th., the same date as CEO. He found two of 
them — the opening of the Suez Canal, and the establishment of carrier pigeon 
service between Paris and London. 





HAWK BEGETS VIKING BEGETS SCORPIO 


The development cycle that began with Hawk and produced Viking was completed by Scorpio, announced 
in the new year as the MV/15000 series of mid-range superminis. It could be said that the three machines 
in this series came free from the Viking effort — all of them were based on the same minimum board 
set, and the only thing needed to upgrade from one system to the next was a single-board CPU. Speaking 
in New York on behalf of the development community, Tom West explained it to reporters like this: 


"We explored a new world in the MV/20000 — working with our vendors on their unproven technology, 
learning how to build a single-board CPU, and tuning our process to be simple and efficent — until we 
had the densest realization of a 6- and 12-MIPS machine in the industry, at the lowest cost to produce. 
The next logical step was to fill out the product line with technology we'd already pioneered. Today, 
using common components from the mid-range to the high end, Data General is now in a position to 
enjoy the economies of backward-integration in a way that it's competition will not — economies that 
come from doing it all on one silicon design, instead of two or four. 


". People have asked me how DG does this — how we build an MV/ processor on one board when 
comparable machines can take 6 to 15 times that many. As simple as it may sound, that design is very 
highly leveraged by a knowledge base within the company of world-class engineers who've all designed 
several MVs prior to this one. By the MV architecture itself, which is easier to implement as a small fast 
machine. By the willingness in development to take the technology risks necessary to play on the leading 
edge. And by the recognition in marketing that a smooth upgrade path of single-board replacements 
could be a differentiator in this business. 


“But perhaps there’s a still simpler answer. In many companies with far-flung, diverse organizations, the 
need to deliver the 2 to 6 MIPS performance range would have looked like opportunities to design even 
more machines. This has been a common failure in our industry, driven more by the politics of large 
corporations than sound business sense. Even in my own organization, the solution to the mid-range did 
not come easily — it required considerable self-discipline to recognize that we already had one. 


"This is a bright moment for Data General and its customers, and an opportune one for industry watchers 
to understand a real differentiator between us and our principle competitors, IBM and DEC. Never have 
our three product lines been so close in positioning — yet it's taken these companies six years and many 
iterations of refining their product lines, only to end up somewhere short of where Data General is today. 
.. | don't know how many engineers it took to design the 4 members of the 9370 family or the 6 members 
of the 8000 series DEC machines, but it took us less than a half-dozen engineers to do the MV/15000 
series. I guess if you get it right the first time, you don't have to do it the second and the third.” 


Afterwards a few of the MV/15 principals remarked on how smoothly the Scorpio program had gone 
compared to anything else in their experience. As one of them said later, “West could have given the 
speech in two sentences: ‘This is by far the easiest project we've ever worked on. Have a nice day.” 
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DG renews its product line in cycles of roughly two to three years’ duration. The glimpses featured in this book 
focused primarily on development activity in the second, and to a lesser extent on the third, year of of this cycle. 
To summarize the aggregate accomplishment of the development community over this period, we compare DG's 
product line at the beginning of the book with the products available at the end. 


BEFORE ... 


The announcement of the MV/10000SX in early 1985 marked the 
transition between DG's second and third generations of 32-bit mini- 
computer systems. At that point the computing power offered by the 
product line ranged from the 0.6 MIPS MV/4000 to the 3.5 MIPS 
MV/10000SX. The price of the basic configurations of these systems 
was $35,000 and $195,000, representing an average price/performance 
ratio of about $57,000 per MIPS — the best in the industry at that 
time. 


The product line also included an integrated ‘departmental system’, 
the MV/4000DC. In an under-the-desk package, this system provided 
all the components — processor, memory, mass storage and com- 
munications interfaces — needed to support up to 32 office users, at 
a basic system cost of $57,000. 


A single-user sister workstation, the DS/4200, was aimed at the tech- 
nical office. It offered high-resolution monochrome or color bit-mapped 
graphics at an entry-level price of $36,000. 


The software platform consisted of DG's proprietary operating system 
AOS/VS, now at rev 5.0, with a well-developed set of utilities, tools 
and languages - the higher-level language compilers now using com- 
mon componts. A hosted version of Unix, MV/UX, had recently been 
released to provide the installed base with some capability for running 
Unix applications. 


CEO was at rev 2.0, providing a stable office automation environment 
for word processing, electronic mail, and file management. 


DG's proprietary communications software XODIAC (based on the 
international X.25 protocol) was at rev 4.0. This was complemented by 
DG/SNA, now at rev 4.0, for interconnection with IBM systems. Products 
based on the IEEE 802.3 (Ethernet) standards for interconnection with 
other systems on local area networks (LANs) were also available at 
this time. 


The low end of the product line consisted of the 16-bit DESKTOP 
GENERATION series and the IBM PC-compatible DG/One, the in- 
dustry's first full-function portable PC. 


The DESKTOP GENERATION ran AOS and RDOS applications, many 
based on DG's Business Basic and Interactive COBOL languages. 
Communications was supported by Xodiac, and these systems sup- 
ported CEO, transferring CEO WP documents to larger machines with 
CEO Document Exchange II. 
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The announcement of the MV/15000 series in 1986 completed the 
replacement of DG's entire product line with systems bringing the 
benefits of the latest technological advances. At the high end, the 6.9 
MIPS MV/20000 Model | and the 12 MIPS dual processor MV/20000 
Model 2 were the industry's best price/performance value in their 
class. The mid-range MV/15000 series offered easily upgradeable 
systems from 1.5 to 6.5 MIPS at about $42/MIPS. At the low end, the 
]-MIPS MV/7800 had a base system price of about $27,000. The new 
integrated ‘departmental system’, the MV/2000DC, supported up to 24 
users and had a base price of $17,500. All of these systems had single- 
board CPUs except the MV/2000DC and MV/7800,which implemented 
the entire system on a single-board. 


The new DS/7500-series technical workstations provided a 1-2 user 
mono graphics workstation with 1024 X 800 X 1 resolution and a single- 
user color graphics workstation with 1024 X 800 X 8 resolution. Each 
delivered about 1MWhet of floating-point performance, supported 4-12 
MB memory and 70-280 MB integral disk storage. Base prices were 
$16,000 for the monochrome workstation and $26,000 for the color 
workstation. Both systems implemented the new Graphics Instruction 


Set (GISII). 


AOS/VS, now at rev 7.5 had features to support multiprocessor systems, 
windowed/graphics user interfaces, the GISII, user-friendly system 
management and startup, and larger user communities. A version 
supporting distributed systems on a LAN, AOS/DVS, was also avail- 
able. For applications aimed at non-proprietary platforms, DG/UX, 
now at rev 2, offered Unix running on the complete 32-bit product line 
except for the MV/20000 Model 2. The suite of higher-level languages 
all delivered increased performance with the release of rev 3. 


DG's communications software products had made significant steps 
to accommodate industry standards. XODIAC at rev 5.0 now supported 
the major local- and wide-area network protocols, X.25, XTS, and 
Ethernet (IEEE 802.3). The addition of TCP/IP under DG/UX and 
AOS/VS, and Internet under AOS/VS allowed connectivity into a 
broader range of multivendor installations. 


CEO, now rev 2.20, included word processing, electronic mail, file 
management, data management, spreadsheets, presentation graphics, 
and translation of WP files from other vendor's OA systems. 


In addition, CEO supported connectivity and file transfer from DG's 
new industry-standard low-end systems. As a result, these systems 
offered IBM PC compatability together with file access to DG's pro- 
prietary platform. The DASHER/One, for IBM PC applications, had an 
entry-level price of $1990. The DASHER/286 offered IBM PC-AT class 
performance at about $4000. And the portable DG/One now included 
a model with EL screen and integral 10MB hard disk. 
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EPILOGUE 


We have heard about the process of building computer systems from people who are actually doing it: getting 
up every morning and marshalling the resources, negotiating the interdependencies, defining the technologies 
and debugging them — or “moving rocks," as some like to say. Not surprisingly, many find it difficult to step 
back from this process and measure their work in industry terms. It may be useful, then, to hear what industry 
analysts and consultants had to say about the products of this year in development: 








“Data General's announcements have set the stage for its competitors — and for the years 
to come."! 


“In support of its self-proclaimed role as industry price/ performance leader, DG has produced 
some real screamers for its MV/ family. There is much to compliment DG upon: the sophisticated 
design that reduced board counts in both the Bulldog and Viking, the price/performance line, 
and Bulldog's catering to the unsophisticated systems manager."? 


“The MV/20000 Model 2 is an interesting starting point for Data General's drive into multi- 
processing. ... Compared with systems from the other major minicomputer vendors — and 
even with the ‘paperware’ offerings of multiprocessor-based systems from start-ups — the 
MV/20000 is an exceptionally good value.”? 


“TEO/Electronics has so much of what users demand. [It] handles intercomputer communication 
better than any other system, exploiting the Cericor technology much better than Hewlett- 
Packard has so far. ... Users should be impressed. The traditional vendors of tools for electronics 
design should be chagrined. They have been scooped by a second-tier supplier of hardware 
for electronic design."4 


"CEO is by far the most integrated of the three systems [DG, Wang and DEC], with a consistent, 
well-thought-out interface. It has also done the most to provide conversions to the PC world 
and has the most complete interface to IBM’s DISOSS."® 


"The price difference and the performance difference is so significant that data processing 
[managers], even if they are tied to DEC, can't help but look at this.”® 


“They [Data General] have an amazing ability to offer the next level of technology before 
others.”” 


"It appears that the company has executed its product development plan flawlessly."® 


Seen from the outside, the execution of Data General's new product line did indeed appear "flawless." Yet this 
effort had its successes and failures like any other, as the people in this book attest. What comes through in 
many of their stories is that each development cycle is part of a continual process in which products — and 
people — get better: 


The designers of the SMI were informed by their experience on the DESKTOP GENERATION user interface. In 
RTP, the experience of doing a hosted Unix enabled designers to optimize the native product more effectively. 
One hardware engineer built on his experience with Hawk to do the Viking FPU, and another engineer built 
on that to do Scorpio. Taking a lesson from the past, CEO development managers initiated a highly disciplined 
planning and QA process. And the manager of DXA said of his staff, "Given the level of understanding they 
now have of the IBM environment, there's probably not much they couldn't do." 


Many industry-watchers believe that if Data General is the best provider of new technology across a broad 
range of products, it is because of this ability to continually build on the knowledge gained from each successive 
development cycle. For the people engaged in this process, we hope this book provides a useful picture of the 
past as they go forward to build the future. 
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A YEAR IN DEVELOPMENT 

is an anthology of stories about the 
process of designing and manufacturing 
computer systems, told by some 50 em- 
ployees at four locations across Data 
General's R & D community. Individ- 
ually, each story represents a unique 
point of view about some aspect of 
technology or the development process. 
Collectively, these stories articulate cer- 
tain fundamental truths about systems 
development and capture the spirit of 
an R & D organization that has been 
called the most successful in the com- 
puter industry. 


Although it would be impossible to ren- 
der the full scale of endeavor in any 
development year, the projects that 
come to fruition in the course of this 
book completed a three-year process of 
replacing Data General's product line. 
From the MV/10000SX to the MV/15000 
series, this process is examined with in- 
telligence and candor, in the words of 
the people who know it best. 


Meanwhile, the process continues. As 
new technology initiatives take the cor- 
poration a generation-step further, A 
Year In Development remains a snap- 
shot of a product line and people, fro- 
zen in time as they never could be in 
reality, somewhere on the way from 
what has been to what will be. 


Mo 


G 


p 


hee 


12-@43165-08 


7 





